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Vorwort 


Vorwort 


Das vorliegende Buch erscheint aus Anlaß des zehnjährigen Bestehens des Be- 
triebssystems SINIX — des UNIX der Siemens Nixdorf Informationssysteme AG. 
Es ist Ziel des Buchs, einen umfassenden Überblick über SINIX zu geben und zu 
zeigen, warum gerade SINIX und seine Komponenten in besonderem Maß für den 
kommerziellen Einsatz geeignet sind. 


Meinen Dank möchte ich an dieser Stelle Klaus Gewald aussprechen, dem Leiter 
des Bereichs Systemtechnische Entwicklung Open Systems bei der Siemens 
Nixdorf Informationssysteme AG. Er war es, der die Idee zu diesem Buch hatte und 
seiner Förderung ist auch die erfolgreiche Verwirklichung zu verdanken. Die Arbei- 
ten am Buch wurden koordiniert von Volker Dulich, dem Leiter der SINIX-Ent- 
wicklung und von Rainer Zimmer, unserem Vertreter bei X/Open, dem Open Sy- 
stems Konsortium. Besonders verpflichtet bin ich David Ortmeyer, Valdur Koha 
und Eberhard Petri von der Research and Development Division, Burlington 
(USA), durch deren tatkräftige Unterstützung meine Arbeit erst ermöglicht wurde. 


Mehr als vierzig Mitarbeiter von Siemens Nixdorf aus den Bereichen Technik, Ent- 
wicklung und Dokumentation haben Beiträge für dieses Buch geliefert. Hinter ih- 
nen stehen die Abteilungen, welche die ganze breite Palette der SINIX-Produkte 
entwickeln: das Betriebssystem SINIX selbst, Werkzeuge und Arbeitsumgebungen, 
aber auch Anwendungsprogramme, die von SINIX unterstützt werden. Ihre Namen 
erscheinen in alphabetischer Reihenfolge am Ende des Vorworts. 


Ich hoffe, daß es mir gelungen ist, all diese Beiträge zu einem Buch zusammenzu- 
fügen, das für Sie als Leser nicht nur interessant, sondern auch nützlich ist. 


John J. Abbott 
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1 Einleitung 


Überblick 


Das Erscheinen dieses Buches fällt in eine Zeit, in der kommerzielle Anwender ver- 
suchen, den Einsatz ihrer Computer so zu planen, daß der einmal festgelegte Weg 
auch in der Zukunft erfolgreich beschritten werden kann. Die Fortentwicklung der 
Computer-Hardware und der Netzwerke bietet die Möglichkeit, die zu erledigenden 
Aufgaben mit immer kleineren Computern und im Netzverbund zu lösen. Damit 
kommerzielle Anwender aus dieser Fortentwicklung Nutzen ziehen können, benö- 
tigen sie offene Computersysteme; denn offene Computersysteme unterstützen 
standardisierte Betriebssystemschnittstellen und Netzprotokolle. Damit ist sicher- 
gestellt, daß die Anwendungsprogramme portierbar sind, und die Computer im 
Netzverbund miteinander kommunizieren können. 


Welche Bedürfnisse muß eine Firma heute bei der Anschaffung von Computer- 
systemen berücksichtigen? 


® Midrange Systeme sind heute so leistungsfähig, wie es vor kurzem noch Groß- 
rechner waren. Hochleistungs-PCs stoßen in die Leistungsbereiche der Midran- 
ge-Systeme vor. 


® Unterschiedliche Computerarchitekturen, wie Mainframes (Großrechner), Ser- 
ver (z.B. Minicomputer), Workstations und PCs sollen zu einem Ganzen inte- 
griert werden. 


Verteilte Netzwerkarchitekturen ermöglichen es, unterschiedliche Computer in 
Netzwerken als dezentrale Ressourcen einzusetzen. 


® Große Datenbanken und Online-Transaktionssysteme, traditionell eine Domäne 
der Großrechenanlagen, werden nun auf Midrange-Servern und auf Client-Ser- 
ver-Architekturen im Netzverbund verfügbar. 


1 Einleitung 


® Entwickler können leistungsfähigere Benutzerschnittstellen entwerfen, seit es 
Midrange-Systeme mit komfortablen Bedienoberflächen, leistungsfähigen Bild- 
schirmen und Programmen mit Fenstertechnik gibt. 


® Es soll eine einheitliche Benutzerschnittstelle vorhanden sein, mit der alle An- 
wendungsprogramme auf allen Plattformen bedient werden können. 


® Die Möglichkeiten von modernen Benutzerschnittstellen werden gerne voll aus- 
genutzt. Dabei soll jedoch zusätzlich die Möglichkeit bestehen, die gleiche An- 
wendung auch auf weniger teuren Terminals zu betreiben, indem man lediglich 
eine weniger aufwendige Benutzerschnittstelle einsetzt. 


® Kunden möchten die Möglichkeit haben, bei den unterschiedlichsten Software- 
Häusern kaufen zu können. Die heterogene Hard- und Software soll dabei leicht 
zu integrieren sein, denn kein Kunde will sich auf Gedeih und Verderb an einen 
Anbieter oder ein System binden. 


® Anwender wünschen sich eine Bedienoberfläche, mit der sie Zugang zu einer 
breiten Palette von Ressourcen haben, seien es nun Werkzeuge zur Steigerung 
der individuellen Leistung, wie ein Tabellenkalkulationsprogramm, ein Textver- 
arbeitungssystem, ein Datenbankverbund oder aber so sensible Anwendungen 
wie Online-Transaktionssysteme. 


Dieses Buch soll Ihnen zeigen, wie Computersysteme, die auf SINIX, dem UNIX 
der Siemens Nixdorf Informationssysteme AG, basieren, einer Firma oder Behörde 
helfen können, optimal auf diese Situation zu reagieren. Dieses Einleitungskapitel 
soll drei einfache, aber wesentliche Fakten herausstellen: 


®e SINIX ist UNIX 
® SINIX ist ein offenes System 
® SINIX ist ideal für den kommerziellen Computereinsatz geeignet 


Das Buch stellt schwerpunktmäßig spezifische Einsatzgebiete für SINIX vor. Es 
soll Geschäftsführern, Managern, Systemverwaltern oder Consultants Rat und Hilfe 
geben, denn Sie müssen entscheiden, welche Computer gekauft werden, Sie müssen 
Wissen vermitteln und beraten, Sie müssen Computersysteme und Netzwerke be- 
treiben. Neben den ausführlichen Informationen über das Betriebssystem SINIX 
selbst gibt Ihnen das Buch einen ausgezeichneten Überblick über die aktuelle Com- 
putertechnologie, deren Standards und gängige Produkte. 


l Einleitung 


SINIX ist UNIX 


Als der Name SINIX geprägt wurde, stand er für das „UNIX von Siemens“. Seit Zu- 
sammenschluß des Bereichs Daten- und Informationstechnik von Siemens einer- 
seits und Nixdorf andererseits, steht SINIX für das „UNIX von Siemens Nixdorf“. 
SINIX ist UNIX, denn es basiert auf dem weltweit gültigen Industriestandard für 
UNIX, dem System V Release 4 (SVR4), das der Siemens Nixdorf Informations- 
systeme AG von den UNIX System Laboratories (USL;) geliefert wird. 


SINIX ist ein offenes System 


SINIX war und ist ein offenes System, es ist eine Weiterentwicklung des klassi- 
schen offenen Systems UNIX. Die Computerabteilungen von Siemens und Nixdorf 
(1990 zur Siemens Nixdorf Informationssysteme AG vereinigt) unterstützten schon 
früh die Idee der offenen Standards: 1984 gehörten sie zu den Gründungsmitglie- 
dern von BISON (Bull, ICL, Siemens, Olivetti und Nixdorf), einem Konsortium, 
aus dem nach dem Beitritt weiterer Mitglieder schließlich X/Open hervorging. 
X/Open, obwohl ein privates Konsortium und kein Standardisierungsgremium, ist 
heute die führende Organisation im Bereich der offenen Systeme. Hier wurden und 
werden standardisierte Schnittstellen festgelegt und veröffentlicht, die allgemein als 
verbindlich und von umfassender Bedeutung für offene Computersysteme aner- 
kannt werden. Heute führt jede SINIX-Version das X/Open Warenzeichen. Es be- 
scheinigt, daß SINIX alle Standards, die von X/Open festgelegt wurden, nachprüf- 
bar erfüllt. 


Was ist unter einem offenen System zu verstehen? Das Institute for Electrical and 
Electronics Engineers (IEEE), Urheber der Standards für Portable Operating Sy- 
stems Interfaces (POSIX, nunmehr in den X/Open Standard integriert), definiert ein 
offenes System wie folgt: 


Ein offenes System ist ein System, das standardisierte Schnittstellen, Dienste und 
unterstützende Formate zur Verfügung stellt. Damit wird erreicht, daß konventions- 
gemäß entwickelte Software folgenden Leistungsmerkmalen genügt: 


® Portierbarkeit über Systemgrenzen hinweg 
® Kommunikationsfähigkeit mit anderen Anwendungen 


® Konsistent gestaltete Bedienoberfläche für einheitliche Bedienbarkeit 


1 Einleitung 


Die Schnittstellen müssen dabei folgenden Anforderungen erfüllen: 


® sie werden veröffentlicht 


® sie werden in einem offenen Meinungsbildungsprozeß auf dem neusten Stand 


gehalten 
® sie stehen in Übereinstimmung mit internationalen Standards 


Der Verbreitung von offenen Systemen sind Anwenderorganisationen, Hersteller 
und Standardisierungsgremien gleichermaßen verpflichtet. Durch sie werden Stan- 
dards und Systeme entwickelt, um die Abhängigkeit von einem einzelnen Anbieter 
zu verringern und die Flexibilität zu erhöhen. 


Die Zahl der Standards, die auf Computersysteme Einfluß nehmen, ebenso wie die 
Liste der Organisationen, die sich in der Entwicklung und Förderung solcher Stan- 
dards engagieren, ist lang. Im Anhang finden Sie eine entsprechende Übersicht. 


Es sind zwei Besonderheiten, die ein offenes System auszeichnen: 


® die Fähigkeit, im Netzverbund mit anderen Systemen zu kommunizieren und 


zusammenzuarbeiten 


® die Unterstützung der unterschiedlichsten Standardschnittstellen, seien es Hard- 
wareschnittstellen, Schnittstellen zwischen den verschiedenen Betriebssyste- 
men oder grafische Bedienoberflächen 


Sind diese Gegebenheiten erfüllt, so ist ein System als offen zu bezeichnen. Denn 
damit ist auch das Ziel erreicht, das mit offenen Systemen verbunden ist: Unabhän- 
gigkeit von Anbietern und den Einschränkungen proprietärer Systeme. 


Wenn man von der Fähigkeit von Computern spricht, mit anderen Systemen im 
Netzverbund zu kommunizieren und zusammenzuarbeiten, so meint man damit, 
daß ein Kunde sich die unterschiedlichsten Computer von den verschiedensten An- 
bietern kaufen kann, die Systeme aber trotzdem miteinander sozusagen sprechen 
können. Dies bedeutet natürlich auch, daß Computer der unterschiedlichsten Größe 
und Komplexität, seien es nun Großrechner, Mehrbenutzer-Systeme, Workstations 
oder PCs, immer die Fähigkeit haben, untereinander Daten auszutauschen. Die An- 
wender dieser Computersysteme können mit E-Mail Nachrichten verschicken und 
Dateien austauschen. 


l Einleitung 


Ein offenes Betriebssystem erfüllt idealerweise folgende Anforderungen: 


® ces verfügt über standardisierte und sorgfältig dokumentierte Betriebssystem- 
Schnittstellen für Anwendungen 


® es ist nicht Eigentum einer einzigen Firma 


® esistbinär und als Source verfügbar, und die Verfügbarkeit wird nicht durch Li- 
zenzbedingungen oder überhöhte Lizenzgebühren eingeschränkt 


® es ist auf einer breiten Hardware-Palette verfügbar 


® eskann vom PC bis zur Großrechenanlage an die unterschiedlichsten Rechner- 
typen angepaßt werden 


® es ist leicht auf neue Hardware-Plattformen mit den unterschiedlichsten Archi- 
tekturen portierbar 


® es unterstützt eine breite Palette von Peripheriegeräten 
® neu entwickelte Peripheriegeräte können leicht eingebunden werden 


Kein Betriebssystem kann natürlich diesen Anforderungen in allen Punkten gerecht 
werden. Aber UNIX ist ein Betriebssystem, das diesem Ideal schon sehr nahe 
kommt. SINIX, die Weiterentwicklung des Standard-UNIX von Siemens Nixdorf, 
ist noch einen Schritt weiter. Es hat natürlich alle Eigenschaften des offenen Sy- 
stems UNIX, aber darüber hinaus wurde viel daran gesetzt, es offener als andere 
UNIX-Derivate zu machen. 


SINIX - ideal für den kommerziellen Einsatz 


Siemens Nixdorf sieht seine Marktanteile vor allem im kommerziellen Sektor. Aus 
diesem Grund verkaufen wir auch seit Jahren SINIX-Systeme in diesem Marktseg- 
ment. Deshalb wurde SINIX früher als andere UNIX-Derivate für den Einsatz im 
kommerziellen Bereich ausgebaut, um dadurch die Bedürfnisse des Marktes besser 
zu befriedigen. Der Markt wünscht: 


® erstklassige Anwenderunterstützung mit menügesteuerten Bedienoberflächen 
und umfassender Online-Hilfe 
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® wunverminderte Pflege und Weiterentwicklung der preisgünstigen alphanumeri- 
schen Terminals, da diese bei vielen Anwendungen im kommerziellen Bereich 
eingesetzt werden 


® leistungsfähige Entwicklungsumgebungen zum Entwickeln und Testen von An- 
wendungsprogrammen 


® hervorragende Werkzeuge zur System- und Netzverwaltung 


® Zuverlässigkeit, Sicherheit und Qualität besonders für den kommerziellen Ein- 
satz 


® Produkte für den Rechenzentrumseinsatz, die auf Grund jahrelanger Erfahrung 
den Bedürfnissen und Erwartungen der kommerziellen Kunden entgegenkom- 
men 


® stabile kommerzielle Anwendungen für den Einsatz auf Großrechnern, wie z.B. 
Datenbanksysteme oder Transaktionsmonitore 


SINIX-Anwendungen 


Siemens Nixdorf vertreibt und unterstützt eine breite Palette von Anwendungen für 
SINIX-Systeme. Diese reichen von allgemeinen Büroanwendungen bis zu vertika- 
len Marktlösungen, wie sie von Siemens Nixdorf z.B. für das Bankwesen, den Ein- 
zelhandel und für das Gastronomie- und Hotelgewerbe angeboten werden. Produkt- 
informationen und Informationen darüber, wie Sie diese Produkte bestellen können 
erhalten Sie von den Siemens Nixdorf Zweigniederlassungen. 


Daneben gibt es unzählige Softwarehäuser, die ihre Anwendungen speziell für 
SINIX-Systeme anbieten. Bei Siemens Nixdorf wurden Hunderte dieser Angebote 
gesammelt und in der SINIX Softwarebörse (englisch: SINIX Software Exchange) 
veröffentlicht. 


Eine Fülle von Anwendungen wurde für alle Varianten von UNIX entwickelt und 
auf den Markt gebracht und kann damit auch auf SINIX-Systemen eingesetzt wer- 
den. Diese sind im UNIX-Softwareführer aufgelistet (englisch: UNIX Software Gui- 
de), zu beziehen über die Siemens Nixdorf Zweigniederlassungen. 
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Aufbau des Buchs 


Das zweite Kapitel ab Seite 9 beschäftigt sich mit der Entwicklung von SINIX aus 
dem Betriebssystem UNIX. Es beschreibt die Besonderheiten von UNIX, die dazu 
führen, daß UNIX an erster Stelle genannt werden muß, wenn man von offenen 
Systemen spricht. Dazu gehören insbesondere die Portabilität von UNIX und der für 
UNIX entwickelten Anwendungen. 


Das dritte Kapitel ab Seite 21 beschäftigt sich mit Kommunikation und der Netz- 
werkfähigkeit von SINIX. Die andere hervorragende Eigenschaft eines offenen Sy- 
stems neben der Portabilität ist die Fähigkeit, mit anderen Systemen im Netzver- 
bund zu kommunizieren und zusammenzuarbeiten. 


Die Kapitel vier, fünf und sechs ab Seite 39 befassen sich mit den Arbeitsumgebun- 
gen, die SINIX für die drei wichtigsten Anwendergruppen eines Computersystems 
bereithält: nicht-privilegierte Anwender, Programmentwickler, System- und Netz- 
verwalter. 


Kapitel sieben ab Seite 123 beschreibt die verteilte Verarbeitung. Dies ist ein relativ 
neuer, aber zukunftsträchtiger Ansatz, sich die Stärken von Computernetzen nutz- 
bar zu machen. 


Kapitel acht ab Seite 151 beschreibt detailliert, wie SINIX die Bedürfnisse der kom- 
merziellen Datenverarbeitung und großer Rechenzentren befriedigen kann. 


Kapitel neun ab Seite 177 beschreibt, warum SINIX durch seine besonderen Lei- 
stungsmerkmale im Bereich Verfügbarkeit, Sicherheit und Qualität für den Einsatz 
im kommerziellen Bereich besonders geeignet ist. 


Kapitel zehn ab Seite 209 wagt einen Ausblick in die Zukunft und weist auf einige 
technische Neuentwicklungen hin, die großen Einfluß auf den kommerziellen Ein- 
satz von Computersystemen zu nehmen beginnen. 


Den Abschluß bilden die Anhänge. Anhang A ab Seite 241 ist für Leser gedacht, 
die sich besonders für die Standards von offenen Systemen interessieren. Neben 
verschiedenen Standardisierungsgremien und Industriekonsortien werden auch die 
Standards beschrieben, die von diesen Organisationen und Konsortien entwickelt 
wurden. Anhang B ab Seite 253 enthält ein Verzeichnis wichtiger Abkürzungen, die 
in diesem Buch Verwendung finden sowie deren Auflösungen. Anhang C ab Seite 
259 enthält ein Verzeichnis der verwendeten Literatur. 
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Überblick 


Wenn ein Unternehmen einen Rechner anschafft, spielt die Frage nach dem Be- 
triebssystem, das auf diesem Rechner läuft, eine wichtige Rolle. Die Auswahl eines 
Betriebssystems hat Auswirkungen auf die drei unterschiedlichen Gruppen, die mit 
dem Rechner arbeiten werden: die Anwender, die Anwendungsentwickler und die 
System- oder Netzverwalter. 


Noch vor wenigen Jahren war die Schnittstelle zwischen Rechner und Anwender 
die Kommandozeile, über die Kommandos eingegeben wurden, die eine Anwen- 
dung starteten, den Inhalt einer Festplatte ausgaben, eine Datei anzeigten, usw. Da- 
bei machte es keinen Unterschied, ob es sich bei dem Rechner um einen MS-DOS- 
basierten PC, ein UNIX-basiertes Midrange-System oder auch einen Mainframe- 
Rechner handelte. Heute jedoch stellen die Betriebssysteme mit ihren grafischen 
Bedienoberflächen dem Anwender eine benutzerfreundlichere und natürliche In- 
teraktionsmöglichkeit mit dem Rechner zur Verfügung. Außerdem wird damit die 
Möglichkeit geschaffen, Anwendungen zu erstellen, die die Vorteile der grafischen 
Bedienoberflächen ausnutzen. 


Für den Anwendungsentwickler war das Betriebssystem schon immer eine ent- 
scheidende Komponente seiner Arbeitsumgebung. Das Betriebssystem stellt die Bi- 
bliotheksroutinen, Systemaufrufe und andere Mechanismen zur Verfügung, die der 
Entwickler für die Programmierung seiner Anwendungen verwenden kann. In ei- 
nem umfassenderen Sinn ist das Betriebssystem für den Entwickler wichtig, weil es 
zudem bestimmt, welche Werkzeuge zusätzlich zur Verfügung stehen: Compiler für 
High-Level Programmiersprachen wie C und COBOL, Editoren, Debugger, usw. 
Der Anwendungsentwickler muß normalerweise einen großen Teil seiner Arbeit auf 
eine gut ausgedachte, bedienungsfreundliche Bedienoberfläche verwenden. Auch 
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hier haben die Betriebssystemumgebung und die Programmierwerkzeuge einen 
großen Einfluß darauf, ob man als Entwickler, schnell und effektiv eine gute Be- 
dienoberfläche erstellen kann. 


Für Anwendungen, die eine Kommunikation über ein Netzwerk beinhalten, muß 
sich der Anwendungsentwickler mit Einrichtungen des Betriebssystems oder ver- 
fügbaren Zusatzprodukten befassen, die die Kommunikation mit anderen Rechnern 
über ein Netzwerk unterstützen. 


Aus der Sicht eines System- oder Netzverwalters stellt das Betriebssystem Kompo- 
nenten für administrative Aufgaben wie das Einrichten von Benutzerkennungen, 
die Datensicherung, die Sicherheitsvorkehrungen, die Unterstützung von Netzver- 
bindungen, usw. zur Verfügung. Die System- oder Netzverwalter verwenden oft 
eine ganze Reihe von Betriebssystemschnittstellen und Dienstprogrammen, die von 
Anwendungsentwicklern selten und noch weniger von Anwendern benutzt werden. 
Die Sicht eines Verwalters auf das Betriebssystems ist in der Regel geprägt von der 
Verfügbarkeit und Effektivität dieser Schnittstellen und Dienstprogramme. 


Aus all dem wird ersichtlich, daß die Entscheidung eines Unternehmens, welche 
Rechner angeschafft und mit welchem Betriebssystem sie betrieben werden, sehr 
komplex ist. Die Entscheidung muß die unterschiedlichen Bedürfnisse und Anlie- 
gen der verschiedenen Unternehmensteile berücksichtigen. Wir glauben, daß heute 
in den meisten Fällen ein standardisiertes UNIX-Betriebssystem wie SINIX die be- 
ste Wahl für alle Unternehmensteile und das Unternehmen insgesamt darstellt. 
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UNIX: Ein offenes Betriebssystem 


Das Betriebssystem UNIX wurde ursprünglich in den frühen siebziger Jahren von 
Ken Thompson und Dennis Ritchie in den Entwicklungslabors von AT&T als 
Werkzeug für den internen Gebrauch entwickelt. Aus diesem Anfang entwickelte es 
sich von einem Programmierwerkzeug im Forschungslabor zu dem heutigen kom- 
merziell nutzbaren und erfolgreichen Betriebssystem. 


Aufgrund folgender Stärken wurde UNIX dabei zu dem Betriebssystem für offene 
Systeme: 


® Portabilität des Betriebssystems bezüglich unterschiedlicher Hardware- 
plattformen 


® Portabilität der UNIX-Anwendungsprogramme 

® „Skalierbarkeit“, d.h. Einsatzmöglichkeit vom kleinen bis zum großen Rechner 
® Jeistungsstarke Software-Entwicklungsumgebung 

® hervorragende Dienstprogramme 

® Unterstützung des Multitasking- und Multiuser-Betriebs 

® überragende Unterstützung für die Integration in Netzwerken 


Die Architektur von UNIX ist durch eine hohe Portabilität und Skalierbarkeit ge- 
prägt. Sie kann leicht für viele verschiedene Rechner angepaßt werden und eignet 
sich für einen großen Leistungsbereich, vom High-end-PC bis hin zum Mainframe- 
Rechner. UNIX ist klar strukturiert. Es gibt einen kleinen Systemkern, der alle 
Hardwareabhängigkeiten behandelt und die System- und Anwendungsprogramme, 
die auf dem Systemkern aufsetzen. Alle hardwareabhängigen Teile sind im System- 
kern untergebracht, aber nur 10% des Systemkerns sind hardwareabhängig. 
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Nur ca. 10% des Systemkerns 
sind hardwareabhängig 

Der Systemkern macht ca. 10% 

von UNIX aus 


UNIX-Systemkern 


Betriebssystem UNIX 


Abbildung 2-1: UNIX zeichnet sich durch seine Portabilität aus. Nur ungefähr 1% des Betriebssystems ist hard- 
wareabhängig. 


Bis auf sehr kleine Teile ist UNIX in der High-Level Programmiersprache C ge- 
schrieben. Dies vereinfacht die Portierung von UNIX auf weitere Plattformen. 
UNIX kann mit einem geringen Aufwand auf neue Hardwarearchitekturen ange- 
paßt, sprich portiert werden. Dies ist der Grund dafür, daß UNIX heute hinsichtlich 
der Anzahl der Rechnerarchitekturen, auf denen es betrieben werden kann, an der 
Weltspitze liegt. 


Wollte man den Grund für den Erfolg von UNIX mit einem einzigen Wort beschrei- 
ben, könnte man das Wort „Portabilität”” verwenden. Die Portabilität von UNIX hat 
dazu geführt, daß UNIX von vielen verschiedenen Anbietern propagiert wird, ein 
universelles Anwendungsspektrum und eine hohe Akzeptanz bei Entwicklern und 
Anwendern besitzt. Hand in Hand damit ging die „Offenheit“ von UNIX, d.h. die 
allgemeine Verfügbarkeit der Schnittstellen und der zugehörigen Betriebssystem- 
Software. Die beiden Worte „Offenheit“ und ‚‚Portabilität‘‘ beschreiben wohl am be- 
sten die Idee, die anfangs hinter UNIX stand. Heute muß man in diesem Zusammen- 
hang ebenso die Interoperabilität hervorheben. 
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Die UNIX-Entwicklungslinien 


In der Vergangenheit gab es drei UNIX-Hauptentwicklungslinien: 


® BSD UNIX (Berkeley Software Distribution) fand hauptsächlich im technisch- 
wissenschaftlichen Bereich und auf Workstations Verbreitung. Sun Microsys- 
tems wählte BSD als Basis für ihr Betriebssystem SunOS und fügte als wesent- 
liche Neuerung das NFS (Network File System) hinzu. 


® UNIX System V ist das von AT&T weiterentwickelte UNIX. System V konnte 
sich als „Standard UNIX” im kommerziellen Bereich bei Mehrplatzsystemen 
durchsetzen. 


® XENIX deckte den „Low-end”-Bereich ab und wurde hauptsächlich aufgrund 
des geringen Verbrauchs an Ressourcen auf PCs eingesetzt. 


en 
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Abbildung 2-2: Drei UNIX-Entwicklungslinien sind in UNIX SVR4 zusammengeführt worden. 
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UNIX System V Release 4 


UNIX System V Release 4 (SVR4) ist das Ergebnis der Bemühungen, die Diver- 
genzen von UNIX-Varianten zu beenden. SVR4 vereint die Merkmale der drei 
Hauptentwicklungslinien in einer einzigen UNIX-Version. Hier einige der heraus- 
ragenden Merkmale von SVR4: 


® Durchsetzung als Industriestandard 
® Spezifizierung eines Binärstandards (Application Binary Interface) 
® Verwendung gemeinsam benutzter Bibliotheken 

® Echtzeitverarbeitung 

® Hauptspeicherverwaltung 

® Prozeßverfolgung 


® virtuelles Dateisystem 


Industriestandards 


Industriestandards ermöglichen es den Software-Anbietern, Anwendungen zu er- 
stellen, die einfach zu portieren sind und deren Wert damit auch in Zukunft erhalten 
bleibt. In der Vergangenheit wurden, anders als bei Siemens Nixdorf, von vielen 
Anbietern eigene UNIX-Versionen vermarktet und unterstützt. Sie blieben nicht 
beim erstmals von AT&T und später von UNIX System Laboratories (USL) bereit- 
gestellten Standard-UNIX. Diese anbieter-spezifischen Versionen von UNIX waren 
eine Mischung aus einem offenen System, da es sich weitgehend um ein UNIX-De- 
rivat handelte, und einem proprietären System, da charakteristische Modifikationen 
der Anbieter eingebaut waren. 


Es gibt aber immer mehr Anzeichen dafür, daß diese Firmen sich allmählich in 
Richtung auf das Standard-UNIX (das System V Release 4 der UNIX System La- 
boratories) bewegen. Zum einem, um die eigenen Kosten zu reduzieren und zum an- 
deren, um den Kunden ein offeneres System anbieten zu können. 
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Binärstandard 


Die Einhaltung von Standards sichert den Softwareentwicklungsfirmen die Portier- 
barkeit von Software auf der Quellprogramm-Ebene. Der Käufer einer Software be- 
kommt diese aber normalerweise in binärer Form. In der PC-Welt mit ihren Klones 
ergeben sich daraus keine Probleme. Die meiste „von der Stange“ gekaufte Soft- 
ware ist auf allen Rechnern ablauffähig, da alle Rechner der gleichen Prozessorfa- 
milie angehören. Da das Betriebssystem UNIX auf einer ganzen Reihe von Prozes- 
sortypen ablauffähig ist, wäre eine einzige Binärform für UNIX nicht denkbar. Es 
ist aber möglich, die gleiche UNIX-Software in binärer Form auf Rechnern des glei- 
chen Prozessortyps verschiedener Anbieter ablaufen zu lassen. Sowohl Hersteller 
als auch Käufer der Software profitieren von dieser Binärcodekompatibilität. 


UNIX SVR£4 besitzt einen solchen Binärstandard, das UNIX-ABI (Applications Bi- 
nary Interface). Es handelt sich hierbei um eine detaillierte Beschreibung von Sy- 
stem- und Compilerschnittstellen. Diese Spezifikation ist in einen generischen und 
einen prozessorspezifischen Teil untergliedert. Es existieren gültige ABI-Spezifika- 
tionen für die Prozessorarchitekturen von Intel x86, Motorola, SPARC und MIPS. 
Das ABI garantiert die binäre Ablauffähigkeit konformer Anwenderprogramme. 
Ein zukünftiges Ziel istes, noch einen DDV/DKI-Standard (Device Driver Interface, 
Driver-Kernel Interface) zu etablieren. 


Gemeinsam benutzte Bibliotheken 


Der Mechanismus der gemeinsam benutzten Bibliothek „dynamic shared library” 
erlaubt es, daß mehrere Anwendungen sich den gleichen Code aus einer Bibliothek 
teilen. Die Bibliothek ist also nicht mehr fester Bestandteil der Anwendung, son- 
dern wird nur noch einmal, eventuell für mehrere Prozesse, in den Hauptspeicher 
geladen. Dadurch reduziert sich die Größe des einzelnen Objektprogramms und 
spart somit Festplattenkapazität, zum anderen wird aber auch weniger Hauptspei- 
cher für mehrere geladene Prozesse benötigt. Dies wird durch einen dynamischen 
Binder ermöglicht, der erst zur Laufzeit, beim Zugriff des Prozesses auf die Biblio- 
thek, die Adressen der Bibliotheksroutinen berechnet. Neben der Einsparung an 
Ressourcen besteht der Hauptvorteil darin, Bibliotheken austauschen zu können, 
ohne die Anwendung erneut binden zu müssen. Das führt zu enormen Kostenredu- 
zierungen bei der Auslieferung und Installation von Fehlerkorrekturen. 
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Echtzeitverarbeitung 


Ursprünglich wurde UNIX als Time-Sharing-System konzipiert. Dies bedeutet, daß 
sich alle lauffähigen Prozesse um die CPU bewerben. Das Ziel war, die CPU-Zeit 
gleichmäßig auf alle Prozesse zu verteilen, eine für den Mehrbenutzer-Betrieb not- 
wendige Voraussetzung. Mit der zunehmenden Verbreitung von UNIX entstand 
auch der Wunsch nach einem Einsatz im Bereich der Fertigungssteuerung. Das er- 
fordert, daß gewisse Prioritäten vergeben werden können, so daß ein Antwortver- 
halten in Echtzeit garantiert werden kann. Um die notwendigen Echtzeitanforderun- 
gen zu befriedigen, wurden in SVR4 die zwei Auftragsklassen „Time-Sharing“ und 
„Real-Time“ eingeführt. Der Systemverwalter hat damit die Möglichkeit, die Zeit- 
scheibe, die ein Prozeß erhält und dessen Priorität festzulegen. 


Hauptspeicherverwaltung 


Die Hauptspeicherverwaltung unter SVR4 wurde weitgehend von SunOS übernom- 
men. Wie bei den UNIX-Varianten AT&T UNIX und BSD wurde ein „Demand-Pa- 
ging“-Konzept realisiert, d.h. nur diejenigen Seiten eines Prozesses werden in den 
Hauptspeicher geladen, die aktuell benötigt werden. Nicht benötigte Seiten können 
bei Speicherengpässen wieder auf die Festplatte ausgelagert werden. Völlig neu da- 
gegen ist die Art der Realisierung in SVR4. Als grundlegendes Konzept dienen sog. 
„Mapped Files“, d.h. beliebige Dateien können im virtuellen Adreßraum eines Pro- 
zesses abgebildet werden. Um einen Prozeß zu starten, wird das ausführbare Pro- 
gramm auf der Festplatte vom Systemkern abgebildet. Der Vorteil der neuen Archi- 
tektur der virtuellen Speicherverwaltung besteht in einer effizienteren Ausnutzung 
des Hauptspeichers, da sich mehrere Prozesse die gleichen Seiten teilen können. Da 
es außerdem möglich ist, physikalische Geräte in den Prozeßraum zu legen, ergeben 
sich elegante Möglichkeiten, auch auf die Hardware zuzugreifen. Beim Entwurf der 
neuen virtuellen Speicherverwaltung wurde streng darauf geachtet, eine Untertei- 
lung in hardwareabhängige und hardwareunabhängige Teile vorzunehmen. Die Por- 
tierung des Systems auf eine neue Hardwareplattform verursacht deshalb geringere 
Aufwände im Vergleich zu den alten UNIX-Varianten. 
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Prozeßverfolgung 


Das /proc-Dateisystem ermöglicht es, auf jeden geladenen Prozeß zuzugreifen und 
Diagnose- und Statusinformationen zu erhalten. Dies erleichtert die Fehlersuche in 
Programmen, vor allem wenn die Sourcen einer Anwendung nicht verfügbar sind. 


Virtuelles Dateisystem 


Um alle vorhandenen UNIX-Dateisysteme zu integrieren war es notwendig, zwi- 
schen generischen und Dateisystem-spezifischen Teilen zu unterscheiden. Das vir- 
tuelle Dateisystemkonzept des VFS (Virtual File System) bietet sowohl eine ein- 
heitliche Benutzerschnittstelle für alle Dateisystemtypen, als auch eine generische 
Schnittstelle im Systemkern, damit neue Dateisysteme dem UNIX-Systemkern hin- 
zugefügt werden können. 


Die folgenden Dateisysteme sind in SVR4 integriert: 
® UFS: Berkeley Fast File System 

® SS: Original AT&T UNIX Dateisystem 

® NFS: Network File System der Firma Sun 

® RFS: Remote File Sharing 
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SINIX 


virtuelles Dateisystem 


Abbildung 2-3: Das virtuelle Dateisystem von SVRA4 stellt allen Anwendungen eine einheitliche Schnittstelle für 
verschiedene Dateisysteme zur Verfügung. 


SINIX basiert auf System V Release 4. SINIX ist UNIX auf einer leistungsfähigen, 
stabilen und modular konfigurierbaren Hardware, auf PCs, auf Workstations, Mehr- 
benutzer- und Serversystemen. Aber SINIX ist mehr als nur ein UNIX. Es ist ein 
UNIX mit „Mehrwert. 


Offene Kommunikation 


Das Betriebssystem SINIX stellt alle wesentlichen Kommunikationsschnittstellen 
und -protokolle zum Aufbau von Hochleistungs-Netzwerken mit anderen UNIX- 
Systemen, PCs, Workstations und Mainframe-Rechnern zur Verfügung (siehe Ka- 
pitel “3 Kommunikation und Netzwerke” auf Seite 21). 
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Anwenderfreundliche Bedienoberflächen 


Schon die frühen SINIX-Systeme besaßen ein leicht verständliches Menü-Bedien- 
system für die Verwaltung und Benutzung des Rechners sowie das Starten von Pro- 
grammen. Diese Tradition wurde fortgesetzt, als mit dem Fenstersystem Collage 
eine grafische Benutzerschnittstelle auf Einbenutzer- und Mehrbenutzer-Systemen 
implementiert wurde. Heute werden die grafischen Benutzerschnittstellen in SINIX 
mit dem X Window System (entwickelt am Massachusetts Institute of Technology 
und standardisiert im X/OPEN XPG3 und XPG4) und OSF/Motif erstellt (siehe 
Abschnitt „Das X Window System“ auf Seite 41). 


Breites Software-Angebot 


SINIX selbst wurde im Lauf der Zeit durch viele bedeutende und wünschenswerte 
Funktionen immer weiter verbessert. So wurden zum Beispiel die Sicherheit und die 
Verfügbarkeit erhöht. SINIX bietet außerdem ein leistungsfähiges Spoolsystem, ein 
verteiltes Dateisystem (NFS), ein Dateisystem, das die Verfügbarkeit erhöht 
(VxFS), und vieles mehr. Viele Softwareprodukte werden zusätzlich zur Verwal- 
tung und Bedienung von SINIX-Rechnern angeboten. Zur Entwicklung von An- 
wendungsprogrammen stehen verschiedene Compiler (C, C++, COBOL, FOR- 
TRAN, BASIC, PASCAL-XT, ADA, PROLOG) und verschiedene 
Entwicklungsumgebungen (Editoren und Debugger) zur Verfügung. Verteilte An- 
wendungen können mit Hilfe von Datenbanksystemen, einem Transaktionsmonitor 
und dem „Distributed Computing Environment” (DCE der Open Software Founda- 
tion) implementiert werden. Diese und auch andere Produkte werden in den folgen- 
den Kapiteln beschrieben. 


Breites Hardware-Angebot — Vom Schreibtisch bis zum Rechenzentrum 


Das Betriebssystem UNIX ist das einzige Betriebssystem, das nahezu die gesamte 
Palette der heute erhältlichen Rechner abdeckt. Die Palette reicht vom Monoprozes- 
sorsystem über Multiprozessorsysteme, vom einfachen PC bis in den Mainframe- 
Bereich, in dem verschiedene Prozessortechnologien verwendet werden. 


Seit dem ersten SINIX-System, das mit einem Intel 8086 Prozessor arbeitete, hat 
Siemens Nixdorf SINIX auf jede neue Prozessorgeneration portiert, um den Kun- 
den die beste Hardwaretechnologie und das beste Preis-/Leistungsverhältnis zu bie- 
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ten. Siemens Nixdorf bietet SINIX auf einer Reihe von Plattformen an, vom PC 
über Workstations zu großen Mehrplatzsystemen. SINIX-Systeme mit der gleichen 
Prozessorarchitektur sind binärkompatibel; für unterschiedliche Prozessorarchitek- 
turen gilt eine volle Sourcekompatibilität auf der Anwendungsebene. Die Schnitt- 
stellen sind im SINIX API (Application Programming Interface) definiert (siehe 
Abschnitt „SINIX API“ auf Seite 75). 


Der Vorteil eines einheitlichen Betriebssystems für die gesamte Palette an 
Hardwareplattformen ist offensichtlich. Anwendungen, die auf einer Plattform ent- 
wickelt wurden, sind auf allen Rechnern ablauffähig. Handelt es sich um unter- 
schiedliche Prozessorarchitekturen, muß nur neu übersetzt werden. Die Arbeitsum- 
gebung für den Anwender und die Mittel zur Systemverwaltung sind auf allen 
Rechnern die gleichen, wodurch die Kosten für Ausbildung und Verwaltung redu- 
ziert werden. 


SINIX läuft auf PCs, auf CISC (Complex Instruction Set Computer) Midrange- 
Rechnern und auf RISC (Reduced Instruction Set Computer) Midrange- und High- 
End-Rechnern. 


3 Kommunikation und Netzwerke 


3 Kommunikation und Netzwerke 


Überblick 


Schon seit langem bieten Computerhersteller proprietäre Lösungen für Kommuni- 
kation und Netzwerke an. Im allgemeinen beschränken sich diese Lösungen jedoch 
auf homogene Kommunikationssysteme, die auf die Produkte des jeweiligen Her- 
stellers zugeschnitten sind. Der Funktionsumfang der Netzwerksysteme wurde spä- 
ter im Rahmen von herstellerunabhängigen, übergreifenden Lösungen erweitert, so 
z.B. um elektronische Post (E-Mail), Anmelden an ferne Systeme oder Dateitrans- 
fer. Schließlich kamen Produkte mit dem Versprechen auf den Markt, auf ganz un- 
terschiedlichen DV-Systemen den vollen Leistungsumfang für eine offene Kommu- 
nikation anzubieten. 


Dieses Kapitel beschäftigt sich zuerst mit einigen Netzwerkprotokollen, die aus sol- 
chen herstellerspezifischen Produkten hervorgingen und heute als De-facto-Stan- 
dard anerkannt werden. Im Anschluß daran werden zwei Netzarchitekturen vorge- 
stellt, nämlich die Internet-Protokoll-Familie und die OÖSI-Protokoll-Familie. 
Darauf folgt eine Einführung, wie PCs in Netzwerke integriert werden. Vor diesem 
Hintergrund werden schließlich wichtige Kommunikations- und Netzwerkprodukte 
von Siemens Nixdorf vorgestellt. 
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Eine Reihe von Computerherstellern hatte schon eigene Kommunikationsprotokol- 
le entwickelt, bevor standardisierte Kommunikationsprotokolle auf den Markt ge- 
bracht wurden. Dazu gehörten die System Network Architecture von IBM (SNA), 
die Digital Network Architecture der Digital Equipment Corporation und die Net- 
work Environment Architecture (NEA) von Siemens Nixdorf. Diese Protokolle wa- 
ren in erster Linie für den Einsatz in einem homogenen Computernetz gedacht, ei- 
nen Netzverbund also, der nur aus Rechnern eines Herstellers besteht. Es ist 
natürlich möglich, Rechner unterschiedlicher Hersteller miteinander zu verbinden, 
dafür ist jedoch meist eine aufwendige Umsetzung der Protokolle nötig, selbst dann, 
wenn die passenden Angaben von der Firma zur Verfügung gestellt werden, die die 
Rechte an diesem Protokoll besitzt (Siemens Nixdorf hat dies so gehandhabt). Zur 
Durchführung einer solchen Umsetzung ist häufig der Einsatz zusätzlicher Hard- 
ware erforderlich. 


NEA steht für eine Reihe von Siemens-Nixdorf-spezifischen Protokollen, die von 
Siemens Nixdorf zu einer Zeit entwickelt wurden, als Protokolle mit vergleichba- 
rem Standard von anderer Seite noch nicht verfügbar waren. Siemens Nixdorf ist 
den offenen Kommunikationsprotokollen verpflichtet und unterstützt diese auch in 
den eigenen Produkten. Um unsere Kunden optimal zu versorgen, werden wir aber 
auch weiterhin solche Produkte pflegen, die auf den NEA-Protokollen basieren. So 
arbeiten z.B. die Siemens-Nixdorf-Produkte der TRANSDATA-Serie NEA-kon- 
form. Mit der Zeit wurde die Palette der TRANSDATA-Produkte erweitert. Sie un- 
terstützen nun eine breite Palette von Protokollen, die entweder einen De-facto- 
Standard darstellen oder von offizieller Seite als Standard anerkannt werden, so z.B. 
SNA, TCP/IP, OSI oder ISDN. 
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Internet-Protokollfamilie 


Die ursprüngliche Arbeit an der Internet Protokollfamilie wurde hauptsächlich von 
einer Dienststelle des amerikanischen Verteidigungsministeriums, der Defense Ad- 
vanced Research Projects Agency (DARPA), finanziert. Von der DARPA wurde 
auch das erste weltumspannende Netzwerk mit dieser Technologie, das Internet, ins 
Leben gerufen. Das Wort internet (klein geschrieben) wird verwendet, wenn man 
allgemein von einem Netzwerk spricht, das auf der Internet-Technologie beruht, 
also mehrere Netzwerke untereinander verbindet. Das Wort Internet (groß geschrie- 
ben) wird immer dann verwendet, wenn genau dieses eine Netzwerk der DARPA 
gemeint ist. 


Die Internet-Protokoll-Familie entwickelte sich aus einem Forschungsauftrag für 
ein Paketnetzwerk. Dieses sollte unterschiedliche Übertragungsmedien unterstüt- 
zen und sogar in einer Katastrophensituation sicher funktionieren. Am Anfang gab 
es nur ein Netzwerk, ARPANET, das ein paar Dutzend Computersysteme in den 
USA miteinander vernetzte. Mit dem Aufkommen von verschiedenen Netzwerk- 
technologien, wie z.B. Ethernet, Packet Radio oder Satellitenübertragung, wurde 
eine Methode für die zuverlässige Informationsübertragung über Medien benötigt, 
die keine zuverlässige und fehlerfreie Übertragung garantieren. Informationen, die 
mit Hilfe dieser Medien übermittelt werden, können z.B. durch Radiostörungen 
oder Kollisionen verstümmelt werden oder ganz verloren gehen. 


Die Internet-Protokollfamilie basiert im wesentlichen auf zwei Diensten: 


® einem verbindungorientierten Transportdienst, der vom Transmission Control 
Protocol (TCP) zur Verfügung gestellt wird 


® einem verbindungslosen Netzwerkdienst, der vom Internet Protocol (IP) zur 
Verfügung gestellt wird 


Das Internet-Protokoll bietet auf der Transportebene zwei Dienste an. Das ist zum 
einen das User Datagram Protocol (UDP). Es handelt sich dabei um ein 
verbindungsloses Transportprotokoll der Internet-Familie. Da UDP ein Protokoll 
der Transportschicht ist, benutzt es für die Zustellung IP. Zum anderen ist dies das 
Transmission Control Protocol (TCP). Es handelt sich dabei um ein verbindungs- 
orientiertes Transportprotokoll aus der Internet-Familie. Da TCP ein verbindungs- 
orientiertes Transportprotokoll ist, durchläuft es drei verschiedene Phasen: Aufbau 
der Verbindung, Datenübertragung und schließlich Abbau der Verbindung. 
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Es gibt mehrere Anwendungsprotokolle in der Internet-Familie, die ständig benutzt 
werden: 


® Das File Transfer Protocol (FTP), welches Dienste für die Dateiübertragung zur 
Verfügung stellt. Im Vergleich zum FTNEA-Protokoll von Siemens Nixdorf 
oder auch zum ISO-Standard-Protokoll FTAM ist der Funktionsumfang des FTP 
jedoch gering. 

® TELNET, das ein virtuelles Terminal zur Verfügung stellt. 


® Das Simple Mail Transfer Protocol (SMTP), welches einen Speicher- und Wei- 
terleitungsdienst für elektronisch übermittelte Nachrichten zur Verfügung stellt. 


® Der Domain Name Service (DNS), welcher hauptsächlich eine Abbildung von 
Rechnernamen auf Netzwerkadressen anbietet. 


TELNET 


IP/ICMP 


Medium; Mediumz ..... Medium, 


Bild 3-1. Aufbau der Internet-Dienste 
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Abbildung 3-1 zeigt anhand einer einfachen Übersicht die Internet-Dienste und die 
dabei verwendeten Protokolle. Beim ICMP, einem Protokoll, auf das in der Abbil- 
dung Bezug genommen wird, handelt es sich um das Internet Control Message Pro- 
tocol. Es wird verwendet, um die Internetschicht zu überwachen und hängt eng mit 
IP zusammen. 


Es gibt natürlich weitaus mehr Dienste, die auf TCP/IP aufsetzen und so unter- 
schiedliche Einsatzgebiete haben wie Netzwerkmanagement oder Sprachprotokol- 
le. Die beiden Dienste mit der größten Bedeutung sind derzeit 


® NES, ein verteiltes Dateisystem, das von Sun Microsystems entwickelt wurde. 


Das NFS wird später genauer beschrieben (siehe Abschnitt „Das verteilte Datei- 
system NFS” auf Seite 127). 


® das X Window System, das am Massachusetts Institute of Technology entwik- 
kelt wurde. Das X Window System wird später näher beschrieben (siehe Ab- 
schnitt „Das X Window System” auf Seite 41). 


Es ist bemerkenswert, daß beide Anwendungsprotokolle so aufgebaut sind, daß sie 
von den tatsächlichen Ende-zu-Ende-Diensten zur Datenübertragung unabhängig 
bleiben. Dennoch werden beide, sowohl aus technischen als auch aus wirtschaftli- 
chen Gründen, am häufigsten in Verbindung mit den Protokollen der Internet Pro- 
tokollfamilien eingesetzt. 


OSI-Schichtenmodell 


Im Jahr 1977 begann die International Standards Organization (ISO) mit der Arbeit 
an einem Standard-Schichtenmodell für Computerkommunikation. Man entwickel- 
te das sogenannte Open-Systems-Interconnection-Schichtenmodell. Das OSI- 
Schichtenmodell hat sieben Protokollschichten. Die folgende Übersicht gibt die 
Protokollschichten an und zeigt, welche Aufgaben diese im einzelnen übernehmen: 
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Schicht 1: Physikalische Ebene 


Kontrolle der physikalischen Verbindung 


Bitübertragungsprotokoll 


Schicht 2: Verbindungsebene 


Auf- und Abbau der Verbindungen zwischen Systemen 
Sicherungsprotokoll 
Schicht 3: Netzwerkebene 
Routing 


Vermittlungsprotokoll 


Schicht 4: Transportebene 


Aufbau von Transportverbindungen 


Integrität und Multiplexen der Datenübertragung 


Schicht 5: Sitzungsebene 


Zuweisen von Sitzungen an Transportverbindungen 


Überwachen des Datenaustauschs durch Kontrollmechanismen 


Schicht 6: Präsentationsebene 


Anfordern einer Sitzung 


Koordination der Syntax 


Festlegen des Datenformats 


Schicht 7: Anwendungsebene 


Kontrolle der Anwendungen 


Kommunikationsmanagement zwischen den Anwendungen 
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Das OSI-Schichtenmodell ist nicht an bestimmte Anwendungen gebunden. Der 
Sinn dieser Architektur liegt in der hierarchischen Strukturierung der Bedürfnisse 
eines Kommunikationssystems, damit Softwarehäuser für jede dieser Strukturebe- 
nen Produkte anbieten können, die dann ohne Schwierigkeiten in umfassende Lö- 
sungen eingefügt werden können. Bei diesem Modell ist von entscheidender Bedeu- 
tung, daß es genau festgelegte Schnittstellen zwischen den einzelnen Schichten 
gibt. Denn es geht davon aus, daß aufgrund einer stillschweigenden Übereinkunft 
jede Schicht ihre Dienste der darüberliegenden Schicht an einer geeigneten Schnitt- 
stelle zur Verfügung stellt. 


Die sieben Schichten kann man in Transportdienste (Ebenen I bis 4) und Anwen- 
dungsdienste (Ebenen 5 bis 7) unterteilen. Die Transportdienste stellen einen Ende- 
zu-Ende-Dienst zur Verfügung, der für die Datenübertragung verantwortlich ist. 
Dies wird in einem Buch über das OSI-Modell näher erläutert: „Ende-zu-Ende- 
Dienste kümmern sich um die Datenübertragung. Während sich die Anwendungs- 
dienste um die Informationsvermittlung kümmern, übertragen die Ende-zu-Ende 
Dienste nur Oktette (8-bit-Werte) von einem System zu einem anderen. Dabei spie- 
len Syntax oder Semantik dieser Oktette keine Rolle: Bits sind Bits.“ (“End-to-end 
services are concerned with data transfer. Unlike the application services, which are 
concerned with information transfer, end-to-end services are interested solely in 
moving octets (eight-bit values) from one system to another. The syntax and seman- 
tics of those octets are unimportant: bits are bits.”) [The Open Book, Marshall T. 
Rose, Prentice Hall, Englewood Cliffs, N.J. 1990, S. 35.] 
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Anwendungsebene 


Präsentationsebene 


Sitzungsebene 


Transportebene 


Netzwerkebene 


Verbindungsebene 


Physikalische Ebene 


Anwendungsprotokoll 


Darstellungsprotokoll 


Kommunikations- 
steuerungsprotokoll 


Anwendungsebene 


Präsentationsebene 


Sitzungsebene 


Transportebene 


Netzwerkebene 


Verbindungsebene 


Physikalische Ebene 


Datentransfer 


Abbildung 3-2: Schema der Kommunikation unter Verwendung des OSI-Schichtenmodells. Die eigentlichen Da- 
ten werden von der jeweiligen physikalischen Schicht an die nächste weitergereicht. Der Weg der Verbindung be- 
ginnt beim Rechner auf der linken Seite in der Anwendungsebene. Die Daten werden nach unten weitergereicht, 
sie durchlaufen dabei verschiedene Software-Ebenen des sendenden Rechners und durchlaufen dann analog 
diese Ebenen in der umgekehrten Reihenfolge auf dem empfangenden Rechner. Die einzelnen Protokolle sind 
dabei so aufeinander abgestimmt, daß die Daten in der jeweiligen Schicht richtig aufbereitet und interpretiert wer- 
den. 
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OSI-Dienste 


FTAM (File Transfer Access and Management) 


Dem Wunsch der Anwender nach problemlosem Dateiaustausch steht die Produkt- 
vielfalt auf dem Rechnermarkt mit unterschiedlichen Betriebssystemen und hetero- 
genen Netzwerken gegenüber. Die diversen Betriebssysteme, wie z.B. BS2000, 
MVS, VMS, UNIX (SINIX) und MS-DOS unterscheiden sich in der Methode der 
Dateiverwaltung, in der Art des Dateizugriffs, durch die Satzstruktur usw. so, daß 
diese Strukturen nicht von einem Rechner auf den anderen abgebildet werden kön- 
nen. Zu diesen betriebssystembedingten Besonderheiten für eine offene Kommuni- 
kation kommen die herstellerspezifischen Kommunikationsarchitekturen, wie z.B. 
NEA, SNA und DNA. In der FTAM-Norm (ISO-Norm 8571 aus dem Jahr 1988) 
wird ein international gültiger Standard für Dateiübertragung, Dateizugriff und Da- 
teiverwaltung festgelegt. Damit werden die folgenden dateibezogenen Aktivitäten 
abgedeckt: 


® Dateiübertragung über netzweit gültige virtuelle Dateien 
® Dateizugriff für Workstations ohne eigene Festplatte 

® gemeinsame Ausgabe auf Drucker, Spoolsystem usw. 

® Zugriff auf ferne Datenbanken 


Eine virtuelle Datei ist eine Sammlung von Dateien, vergleichbar mit einem Datei- 
system eines Betriebssystems. Um mit FTAM arbeiten zu können, muß ein System 
eine besondere Schnittstelle anbieten. Um mit FTAM arbeiten zu können, benötigt 
ein Betriebssystem eine Schnittstelle zwischen den Dateisystem-Diensten und den 
FTAM-Diensten. FTAM überprüft eine Datei auf zwei Komponenten. Dies sind 
zum einen Attribute, die Informationen über die Datei geben, und zum anderen der 
Dateiinhalt selbst. Eine Datei ist danach inhaltlich einer der fünf folgenden Gruppen 
zuzuordnen: 
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Der OSI-Standard für E-Mail (Verwaltung von elektronischer Post) ist X.400. Man 
hat von X.400 sogar als von einer „OSI-Flaggschiff-Anwendung“ gesprochen 
[Rose, S. 463]. Im Jahr 1984 hat CCITT eine Reihe von Empfehlungen zur Verwal- 
tung von Meldungen veröffentlicht. Im Jahr 1988 entwickelten hierzu CCITT und 
ISO gemeinsam eine Empfehlung. X.400 besteht aus mehreren Schichten. Die 
äußerste Schicht ist eine Schnittstelle (User Agent) zwischen dem Menschen als Be- 
nutzer und dem E-Mail-System. Diese kommuniziert mit einer Vermittlungsstelle 
(Message Transfer System), die aus einem oder mehreren Message Transfer Agents 
besteht. Ein weiteres Element bildet der Message Store, eine Art vermittelnder Zwi- 
schenspeicher zwischen dem User Agent und dessen lokalem Message Transfer 
Agent. Ein User Agent holt die elektronische Post eines Benutzers aus dem Zwi- 
schenspeicher (Message Store). 


Eine Nachricht im X.400-Format besteht aus zwei Teilen: einer Art Umschlag und 
der Nachricht, die in dem Umschlag steckt. Der Umschlag enthält Informationen 
über den Absender, den Verteiler und einige zusätzliche Informationen, die für die 
Zustellung nötig sind. Die eigentliche Nachricht enthält normalerweise einen Kopf 
mit Absender, Empfänger, Betreff, Sendezeit und einen oder mehrere Textteile. Da 
der sogenannte Textteil nicht unbedingt Text enthalten muß, ist das X.400-Protokoll 
sehr flexibel und zukunftsorientiert, denn es können auch Faxe, Tonaufzeichnungen 
oder Bilder enthalten sein. Das Entwicklungsprojekt Mercury von Siemens Nixdorf 
istein E-Mail-System mit Multimedia-Fähigkeiten, das sowohl mit internet als auch 
X.400 betrieben wird (siehe Abschnitt „Notwendige Infrastruktur” auf Seite 232). 
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X.500 


GDS Administrator 


Anwender 


OSI- Netz- 
Anwendungen Management 


vorhandene 
Daten- 
netze 


N (Fe 


Installation und E-Mail 
Administration Fax 
des Directory- Teletext 
Service 


DCE-Anwen- 
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Büro- gestützte 
Anwendungen Telefone 


XDS API 


Abbildung 3-3: Architektur des im X.500-Standard definierten Directory-Systems. 


31 


3 Kommunikation und Netzwerke 


Das elektronische Teilnehmerverzeichnis nach dem X.500-Standard bietet die 
Möglichkeit, Namen von Objekten auf computer- bzw. netzwerkgerechten Adres- 
sen abzubilden und die Eigenschaften solcher Objekte zu speichern. Diese Objekte 
können Computer, Eingabe-/Ausgabegeräte, Dateien, Anwendungen und Netzele- 
mente und auch natürliche oder juristische Personen sein. Dieses Teilnehmerver- 
zeichnis läßt sich am besten mit den sogenannten weißen und gelben Seiten des Te- 
lefonbuchs vergleichen. Solche Verzeichnisse haben allerdings den Nachteil, daß 
sie unterschiedliche Besitzer und dafür Verantwortliche haben und häufig redundan- 
te oder inkonsistente Informationen beinhalten. Demgegenüber stellt das Teilneh- 
merverzeichnis nach X.500 ein intelligentes, einheitliches und standardisiertes 
Kommunikations- und Eigenschaftsverzeichnis dar. 


Abbildung 3-3 zeigt die im X.500-Standard definierte Architektur des Directory- 
Systems. Es besteht aus Zugangsbausteinen (Clients), genannt Directory User 
Agents (DUA), und den Erbringern von Leistungen (Server), genannt Directory Sy- 
stem Agents (DSA). Die Directory User Agents befinden sich auf Client-Rechnern, 
die Directory-Services befinden sich auf den Server-Rechnern. DUA und DSA 
kommunizieren über das Directory Access Protocol (DAP), die DSAs kommunizie- 
ren untereinander über das Directory System Protocol (DSP). Nutzer des Directory 
Service können E-Mail, Dateitransfer oder verteilte Büroanwendungen usw. sein. 
Zu diesem Zweck bietet der Directory User Agent, ein Anwendungsprozeß im 
Client-Rechner, eine Anwenderschnittstelle. Diese Anwenderschnittstelle (XDS: 
API Directory-Service), von X/Open definiert, steht auch dem Management des Di- 
rectory-Service für Installations- und Verwaltungszwecke zur Verfügung. Die Tren- 
nung von Client und Server gestattet es, neue Clients problemlos hinzuzufügen. 
Darüberhinaus ist es ohne Rückwirkung auf das Gesamtsystem möglich, den Ser- 
ver-Rechner durch einen anderen zu ersetzen oder seinen Aufstellungsort zu verän- 
dern. 


Integration von PCs in Netzwerken 


32 


Ursprünglich waren PCs nur dazu gedacht, die für einen Arbeitsplatz typischen PC- 
Anwendungen, Laufwerke und Drucker bereitzustellen. Aufgrund der Möglichkei- 
ten, die PCs heute bieten (Rechnerleistung, Speicherkapazität, grafische Bedien- 
oberfläche, individuelle Einstellung der persönlichen Arbeitsumgebung, Verfügbar- 
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keit usw.) sowie ihrer steigenden Verbreitung, ist es durchaus sinnvoll, PCs in 
bestehende IT-Lösungen der Unternehmen zu integrieren, bzw. neue IT-Konzepte 
unter Einbeziehung von PCs zu realisieren. 


Die Integration von PCs ist in loser, aber auch in sehr enger Form möglich. Grund- 
sätzlich kann man drei Stufen der Integration unterscheiden, wobei die Grenzen 
zwischen diesen Stufen fließend sind. 


® PCs können zur Terminalemulation verwendet werden, um den Zugang zu an- 
deren Computer-Ressourcen zu ermöglichen, wie z.B. ein Mehrplatz-System 
oder einen Großrechner. Dies kann die Emulation eines 97801-Terminals, eines 
X-Terminals oder eines 3270-Terminals sein. Terminalemulationen bieten die 
Möglichkeit, schon vorhandene Terminals durch PCs zu ersetzen und auf diesen 
PCs parallel dazu PC-Standardsoftware und schon existierende Anwendungen 
einzusetzen. Über entsprechende Multiplex-Mechanismen können auch mehre- 
re Sitzungen parallel durchgeführt werden. Der Einsatz von Terminalemulatio- 
nen ist zudem der erste Schritt, einen allmählichen Übergang von „konventio- 
nellen“ Anwendungen auf Client-Server-Anwendungen zu erreichen. 


® PCs können an ein LAN angeschlossen werden und sich auf diese Weise Res- 
sourcen wie Drucker oder zentral auf Platte gehaltene Daten teilen. Wenn ein 
Midrange-Rechner in das LAN eingebunden wird, kann dieser als Server für un- 
terschiedliche Ressourcen eingesetzt werden, wie z.B. Dateien, Drucker, Daten- 
banken oder Netzverbindungen. Diese Ressourcen werden durch öffentlich zu- 
gängliche Dienste (z.B. File Transfer, SNA Gateways), verteilte Dateisysteme 
(z.B. NFS, DFS) oder Netzwerk-Betriebssysteme (wie z.B. LM/X) zur Verfü- 
gung gestellt. Diese Strategie bietet unter anderem die Möglichkeit, Daten zen- 
tral zu verwalten (Server oder Host) und für PC-Anwendungen zugänglich zu 
machen. Die Daten können lokal weiter bearbeitet und die Arbeitsergebnisse auf 
einem zentral angeschlossenen Drucker ausgegeben werden. 


® Darüber hinaus stoßen wir in Bereiche vor, die den wirklichen verteilten Syste- 
men zuzurechnen sind. 


Die Einbindung von PCs in Netze wird in weiteren Kapiteln dieses Buchs darge- 
stellt (siehe Abschnitt „Integration von SINIX- und PC-Netzen mit LM/X” auf Seite 
128 und Abschnitt „PC-Integration” auf Seite 175). 
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Netzwerkprodukte von Siemens Nixdorf 


TRANSIT 


NEA 
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Siemens Nixdorf wird für den Kundenkreis mit SNA-Netzen weiterhin die Produk- 
te der TRANSIT-Familie anbieten. Dazu gehören Produkte, die SINIX-Systeme in 
die SNA-Umgebung einbinden. Siemens Nixdorf-Produkte sind in der Lage, SNA- 
Netzsegmente vollständig zu ersetzen. Dabei werden SINIX-Rechner als SNA- 
Gateways eingesetzt und erhöhen so die Leistungsfähigkeit beträchtlich. Die Pro- 
dukte der TRANSIT-Familie unterstützen 3270-Emulationen, SNA-Programm- 
schnittstellen, wie z.B. CPI-C, EHLLAPI, LUOAPI, Eingangs- und Service- 
Schnittstellen für NetView, SNA Server, SNA Passthrough, Zugang zu SNA- 
Netzen mittels SDLC, X.25 und Token Ring. 


SINIX-Systeme können auf verschiedene Weise in SNA-Netze eingebunden wer- 
den: 


® SINIX-Systeme können mit einem oder mehreren IBM-Systemen zu einem 
Netzverbund zusammengeschlossen werden. 


® SINIX- und MS-DOS-Netzwerksegmente können mit Hilfe eines SINIX-Ser- 
vers in ein SNA-Netz eingebunden werden. Diese Netzwerksegmente können 
hierarchisch verbunden werden. Auf diese Weise wird es möglich, eine Reihe 
von Netzwerksegmenten mit einem SNA-Netz zu verbinden. 


® SINIX-Systeme können mit anderen Systemen oder Netzwerksegmenten auf 
derselben hierarchischen Ebene zu einem Peer-to-peer Netzverbund zusammen- 
geschlossen werden. 


Das Produkt von Siemens Nixdorf, Network Environment Architecture (NEA), 
wird selbstverständlich von SINIX-Systemen unterstützt. Die Produkte der 
TRANSDATA-Familie erhielten über die Jahre einen größeren Funktionsumfang 
und unterstützen sowohl NEA als auch die Internet-Protokoll-Familie und die OSI- 
Protokoll-Familie. 


FT/FTOS 
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Die ersten TRANSDATA -Netzwerke wurden schon im Jahr 1974 eingerichtet. Sie 
waren ursprünglich für homogene Netze gedacht, wurden aber schrittweise erwei- 
tert. Damit konnten auch Systeme anderer Hersteller eingebunden und zusätzliche 
Protokoll-Architekturen unterstützt werden. So ist es z.B. möglich, Netzwerke in 
TRANSDATA-Norm mit SNA-Netzwerken zusammenzuschließen. 


SINIX 


BS2000 


Abbildung 3-4: Schematischer Aufbau des Dateitransfers zwischen einem IBM-MVS-Host und Systemen mit 
SINIX, MS-DOS und BS2000 bei Verwendung der Produkte der FT-Familie von Siemens Nixdorf. 


Siemens Nixdorf bietet schon seit einigen Jahren File-Transfer-Produkte (FT) an. 
Diese ermöglichen den Datenaustausch mit einer Vielzahl von unterschiedlichen 
Rechnern bei hoher Leistung und breitem Funktionsumfang. Seit FTAM, die OSI- 
Norm für den File Transfer, verfügbar ist, war es die Strategie von Siemens Nixdorf, 
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einerseits den OSI-Standard zu erreichen, andererseits aber den größeren 
Funktionsumfang unserer schon vorhandenen File-Transfer-Produkte zur Verfü- 
gung zu stellen. Die Produkte gemäß Siemens-Nixdorf-Normen sind tausendfach 
installiert und bieten für die nächste Zukunft einen höheren Leistungsumfang als die 
entsprechenden Produkte gemäß FTAM-Norm. Dazu gehören z.B. Folgeverarbei- 
tung im entfernten System, automatischer Wiederanlauf und Datenkomprimierung. 


Der File-Transfer über das FTAM Protokoll (ISO 8571) wird für SINIX-Systeme 
mit FTOS-SINIX durchgeführt, während der File-Transfer über NEA von Siemens 
Nixdorf mit FT-SINIX durchgeführt wird. Dabei wurde FTOS so in die bestehende 
Produktumgebung eingebunden, daß sowohl Koexistenz als auch Migration mög- 
lich sind. Dieser Ansatz bringt für neu gewonnene Anwender und für schon beste- 
hende Systeminstallationen viele Vorteile. 


Siemens Nixdorf bietet für die eigenen Betriebssysteme (z.B. unter BS2000, 
SINIX, TOS, AMBOSS und MS-DOS/WINDOWS) und für IBM-Rechner (unter 
MVS) FT-Produkte an. Da die Siemens-Nixdorf-FT-Normen offengelegt und frei 
zugänglich sind, hat die Digital Equipment Corporation (DEC) für ihre VAX-Syste- 
me unter VMS und ULTRIX mit FTSIE eigene FT-Produkte entwickelt. Dadurch 
können mit Systemen von Siemens Nixdorf Daten leicht ausgetauscht werden. Ne- 
ben diesen bieten Softwarehäuser weitere FT-Produkte an, speziell für die Betriebs- 
systeme OS/2 und MS-DOS. Auf eine einheitliche Funktionalität sowie eine ein- 
heitliche Benutzerschnittstelle innerhalb der FT-Produktfamilie wurde großer Wert 
gelegt. FT-SINIX bietet unter anderem: 


® Symmetrische Übertragungsinitiative 

® Auftragsspeicherung 

® Automatischen Wiederanlauf 

® Datenübertragung mit Folgeverarbeitung 

® Datenkomprimierung 

® File-Management-Funktionen zur Dateiverwaltung 
® FErgebnismitteilung 

® Sicherheitsfunktionen 

® Kommunikation mit IBM-VMS-Hosts 


® Übereinstimmung mit der X/Open BSFT-Komponente 


DIR-X 
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Um in einem großen und weiträumigen Rechnerverbund mit teilweise fehleranfäl- 
ligen Übertragungswegen einen File-Transfer sinnvoll betreiben zu können, ist die 
Verfügbarkeit von größter Bedeutung. Die Produkte der FT-Familie bieten diese Ei- 
genschaften durch komfortable Auftragsspeicherung und automatischen Wiederan- 
lauf. 


DIR-X ist das elektronische Teilnehmerverzeichnis für SINIX-Systeme nach dem 
X.500 Standard von Siemens Nixdorf. DIR-X arbeitet auf INFORMIX- und 
C-ISAM-Datenbanken. Eine MOTIF-Version ist in Kürze verfügbar. Produktver- 
sionen für die Betriebssysteme BS2000 und MS-DOS sind in Entwicklung. 


Stand-alone-Anwendungen und verteilte Anwendungen aller Art können über die 
von X/Open genormte Schnittstelle XDS auf das Directory-System zugreifen. 


Bei der Konzeption und Entwicklung von DIR-X wurden die folgenden Ziele ge- 
steckt und erreicht: 


® netzweite Verfügbarkeit und Eindeutigkeit der Daten (die Datenkonsistenz wird 
z.B. dadurch gewährleistet, daß Informationen jeweils nur an einer Stelle geän- 
dert werden können) 


® flexible Datenstrukturen 

® Unterstützung benutzerfreundlicher Namensgebung 

® FEinsetzbarkeit für verschiedene Anwendungen 

® Unterstützung verschiedener Suchabfragen 

® einheitliche Zugangsberechtigungen und Zugangsüberprüfungen 
® Konformität zum X.500-Standard 

® Konformität zum X/Open XPG4 Directory API 

® einfache Verwaltung 

® Portabilität bzw. Verfügbarkeit auf mehreren Plattformen 


® Kompatibilität mit vorhandenen Netzwerken 
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Mit diesen Eigenschaften bietet der Directory Service von Siemens Nixdorf eine 
wichtige Voraussetzung für einen gut funktionierenden unternehmensinternen und 
-externen Informationsaustausch. Dabei wird die ständige Aktualität und Konsi- 
stenz von Adreßinformationen gesichert. Den Nutzern dieser Dienste bleibt dabei 
die Komplexität der über ein Netz verteilten Dienste verborgen. Darüber hinaus 
wirkt der Directory Service als Integrationsfaktor für unterschiedliche Dienste, An- 
wendungen, Organisationseinheiten usw. Wie hoch die Akzeptanz des Siemens- 
Nixdorf-Produkts DIR-X mittlerweile geworden ist, zeigt sich daran, daß DIR-X 
von OSF als Global Directory Service (GDS) für das Distributed Computing Envi- 
ronment (DCE) ausgewählt wurde. Das macht den Siemens-Nixdorf-Directory-Ser- 
vice nach X.500 zur Industrienorm. 


CMX ist der SINIX-Kommunikations-Manager. CMX stellt SINIX-Anwendungen 
eine Schnittstelle zur Verfügung, die von den zugrundeliegenden Transportdiensten 
unabhängig ist. Alle nötigen Anpassungen an die unterschiedlichen zugrundelie- 
genden Transportdienste werden von CMX durchgeführt. CMX unterstützt eine 
Reihe von Transport-Schnittstellen (APT), z.B.: 


® XTI, Transport-Schnittstelle von X/Open nach XPG4 
® TLI, Transport-Schnittstelle von UNIX SVR4A 
® sockets, Internet-Transport-Schnittstelle 


® ICMX, Standard-Transport-Schnittstelle von Siemens Nixdorf 
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Überblick 


Computeranwender haben meist wenig Interesse an den Technologien und Mecha- 
nismen, die einem Computer zugrunde liegen. Anwender möchten eine Aufgabe er- 
ledigen und erwarten vom Computer, daß er sie dabei unterstützt, produktiver zu ar- 
beiten. Einige Kriterien für ein Computersystem sind aus der Sicht des Anwenders 


® ]eichte Bedienbarkeit 

® einheitliche Oberfläche 
® überzeugende Leistung 
® minimaler Lernaufwand 


Anwender bevorzugen eine einheitliche Bedienoberfläche für unterschiedliche An- 
wendungen, die auf einem Rechner laufen. Anwender, die mit mehr als einem Rech- 
nertyp arbeiten, wünschen gleiche Bedienoberflächen für verschiedene Hardware- 
plattformen. Ein Anwender, der vorwiegend auf einem SINIX-System arbeitet, 
gelegentlich jedoch einen MS-Windows PC benutzt, hätte gerne auf beiden Rech- 
nern dieselben Fenstertypen, Menüs, usw. 


Da Bedienoberflächen für Anwendungsprogramme nicht nur von Siemens Nixdorf 
realisiert werden, sondern auch von Softwarehäusern und hausinternen Entwick- 
lungsabteilungen beim Kunden, beschreibt dieses Kapitel die Werkzeuge, die 
SINIX für die Entwicklung von Bedienoberflächen zur Verfügung stellt, sowie die 
Charakteristika der Bedienoberflächen, die mit diesen Werkzeugen erstellt werden 
können. Es wurde viel Mühe auf Werkzeuge und Anwendungshilfen verwandt, die 
Siemens Nixdorf anbietet, um gute, benutzerfreundliche Bedienoberflächen für An- 
wendungsprogramme bereitzustellen, die unter SINIX entwickelt wurden und unter 
SINIX ablauffähig sind. 
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Im vorliegenden Kapitel werden zuerst grafische Bedienoberflächen vorgestellt, im 
Anschluß daran die eher traditionellen alphanumerischen Oberflächen — solche, 
die für Eingaben und Anzeigen auf die Tastaturzeichen (Buchstaben und Zahlen) 
begrenzt sind. Zudem wird ein im Entstehen begriffener Standard zu diskutieren 
sein, der konzipiert wurde, um auch für alphanumerische Bildschirmarbeitsplätze 
ein Fenstersystem bereitzustellen. Das Kapitel schließt mit einer Besprechung der 
Werkzeuge zur Internationalisierung von Bedienoberflächen auf SINIX-Systemen. 


Grafische Bediensysteme 
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In Vorwegnahme des Trends zu grafischen Bediensystemen wurde SINIX zu einem 
frühen Zeitpunkt seiner Entwicklung mit der COLLAGE-Fenstertechnik für Ein- 
und Mehrplatzsysteme ausgestattet. Um der Standardisierung gerecht zu werden, 
die seitdem im Bereich der grafischen Bediensysteme eingesetzt hat, unterstützt 
SINIX jetzt X Window und OSF/Motif. Grafische Bediensysteme werden unter 
SINIX zudem durch das Produkt SINIX/windows unterstützt, das auf X Window 
und OSF/Motif aufbaut. 


Nach Untersuchungen der Marktforschungsinstitute XBusiness und Dataquest 
zeichnet sich der Trend zu den GUIs (Graphical User Interfaces), den grafischen 
Bediensystemen, klar ab. OSF/Motif hat sich danach als „‚das“ grafische Bediensy- 
stem unter UNIX durchgesetzt. Aus diesem Grund wurde OSF/Motif zur strategi- 
schen Schnittstelle für grafische Bediensysteme und auch im SINIX API festge- 
schrieben. Erst kürzlich wurde OSF/Motif von COSE (Common Open Software 
Environment), einer Gruppe, in der die wichtigsten UNIX-Anbieter wie HP, IBM, 
SunSoft u.a. vertreten sind, als gemeinsam unterstützte Basis für grafische Bedien- 
oberflächen festgelegt. 


OSF/Motif steht seit 1990 auf SINIX-Systemen zur Verfügung. Da Motif im OSF- 
Original im wesentlichen nur aus einem Fensterverwalter und Elementen (Widgets) 
für die Gestaltung von Oberflächen besteht, erfolgte schrittweise eine Erweiterung 
um notwendige und für eine komplette Desktop-Umgebung noch fehlende Kompo- 
nenten. X Window, OSF/Motif und Erweiterungen von Siemens Nixdorf wurden 
zum Produkt SINIX/windows zusammengefaßt, so daß die Einheitlichkeit der gra- 
fischen Bediensysteme auf allen SINIX-Hardwareplattformen sichergestellt ist. 
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Das X Window System 


1984 standen die Computerlabors des MIT (Massachusetts Institute of Technology) 
vor folgendem Problem: Es wurde eine große Anzahl von Computern verschiedener 
Hersteller in unterschiedlichen Leistungsklassen und mit unterschiedlichen Be- 
triebssystemen eingesetzt. Diese unterschiedlichen Computersysteme sollten in ein 
Netzwerk eingebunden werden, so daß alle Rechner untereinander Daten und Nach- 
richten austauschen konnten. Dies führte zur Idee, ein Programm, das auf einem 
Computer abläuft, von einem anderen Computer aus zu kontrollieren. Wenn Com- 
puter in der Lage waren, Daten auszutauschen, sollten sie auch Rechenleistung aus- 
tauschen können. Schließlich leiteten diese Überlegungen die Entwicklung des 
X Window Systems ein. 


Leistungsstarke Rechner sollten Programme ausführen, für die andere Rechner zu 
langsam waren. Trotzdem sollten die Benutzer dieser langsameren Rechner nicht 
gezwungen sein, an einen anderen Bildschirmarbeitsplatz zu wechseln. Mit diesen 
Überlegungen als Leitlinie entwickelte die MIT-Gruppe ein System, das die Anzei- 
ge der Ausgaben eines Computers auf einem anderen Computer ermöglichte. Pro- 
gramme wurden zwischen dem Frontend (dem Bildschirm und der Tastatur) und 
dem Backend (dem eigentlichen Rechner) aufgeteilt. Da so die Programme vieler 
Computer von einem einzigen Computer kontrolliert wurden, dachte man an eine 
Ausgabe in verschiedenen Fenstern. Um diese Funktionen bereitstellen zu können, 
mußte die Kommunikation zwischen zwei Computern durch ein festgelegtes Proto- 
koll unterstützt werden. Zwischen Anwendungsprogramme und den Bildschirm 
wurde eine Schnittstelle gesetzt, um Anwendungen gegen unterschiedliche Grafik- 
hardware und die Unterscheidung zwischen Frontend und Backend abzuschirmen. 
Bei einem Wechsel der Grafikhardware sollte nur noch die Schnittstellensoftware 
angepaßt werden. Da diese Schnittstelle für alle Anwendungen gleich ist, muß der 
anfallende Anpassungsaufwand nur einmal für jede neue Grafikhardware-Kompo- 
nente geleistet werden. 


Die Grundlage der Arbeit des MIT bildete das Fenstersystem „W“, das von der 
Stanford Universität für Testzwecke entwickelt worden war. Um das MIT-Projekt 
vom Stanford-Projekt unterscheiden zu können, wählte man als Namen für dieses 
Fenstersystem den nächsten Buchstaben im Alphabet, das „X“. Da der Schwer- 
punkt der Arbeit darauf lag, ein leicht portierbares System zu entwickeln, wurde ei- 
nem modularen Ansatz der Vorzug gegeben. Das Projekt baute auf einem Satz von 
Basisfunktionen auf; neue Funktionen wurden nur in das System aufgenommen, 
wenn sie mit den bereits bestehenden Funktionen nicht dargestellt werden konnten. 
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Schon bald wurde die Entscheidung getroffen, X Window an alle Interessenten zum 
Preis der Kopierkosten weiterzugeben. Die Entwickler sicherten so die schnellst- 
mögliche weite Verbreitung von X Window. Die Vorteile einer weiten Verbreitung 
wurden bald offensichtlich. X Window wurde schnell übernommen und andere Ent- 
wickler außerhalb des MIT leisteten wertvolle Beiträge zu seiner weiteren Entwick- 
lung. 1986 kündigte DEC das erste kommerzielle X Window System für seine VAX 
Station IUGPX an. 


X Window ist nicht auf UNIX-Systeme beschränkt. Es gibt X Window Server und 
X Clients für viele Rechner. Mittlerweile wurde die Verantwortung für die Weiter- 
entwicklung von X Window vom MIT auf das X Konsortium übertragen. In diesem 
Konsortium haben sich mehr als 30 Hersteller und Organisationen zusammenge- 
schlossen, darunter auch Siemens Nixdorf, um die weitere Entwicklung von X Win- 
dow zu fördern und die Einhaltung des Standards zu überwachen. 


Im Gegensatz zu MS-Windows, Presentation Manager von OS/2 und MacOS gibt 
es unter X Window keine Vorschriften, wie ein Programm bestimmte Aufgaben zu 
erfüllen hat. Diese Entscheidungen wurden bewußt den Entwicklern von X Clients 
überlassen, um deren Kreativität nicht einzuschränken. So kann der Entwickler ei- 
nes X Client die Gestaltung der Benutzerumgebung einschließlich der Anordnung 
von Buttons und Menüs selbst bestimmen. Der Entwickler wird nicht durch restrik- 
tive Design-Regeln eingeengt. Andererseits könnte der Anwender durch eine Viel- 
falt von Designvorgaben für Bediensysteme verwirrt werden und der problemlose 
Umgang mit Anwendungsprogrammen behindert werden. 


Abgesehen von Überlegungen, die das Copyright der Merkmale von Bedienoberflä- 
chen, ihr „Look und Feel” betreffen, kann ein individuelles Design angewandt oder 
aber ein bereits bestehendes Design übernommen werden. Entwicklern wird nicht 
vorgeschrieben, wie eine bestimmte Funktion zu implementieren ist. Es bleibt ihnen 
überlassen, ihren persönlichen Stil zu wählen. 
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OSF/Motif 


Obwohl X Window als System zur Erstellung grafischer Bediensysteme im Ver- 
gleich zu anderen Systemen viele Vorteile bietet (Netzwerkunterstützung, frei kon- 
figurierbar, hardware-unabhängig), ergaben sich sowohl für den Anwender als auch 
für den Entwickler ernstzunehmende Einschränkungen. Die Funktionen, die dem 
Entwickler durch das ursprüngliche X Window System zur Verfügung gestellt wur- 
den, waren nicht leistungsfähig genug, und die Toolkits, die darauf aufsetzten, nur 
schwer portierbar. Von System zu System mußte sich der Anwender mit neuen Fen- 
sterverwaltern vertraut machen, da das Standard-Verwaltungsprogramm des MIT 
auf fast allen X-Systemen durch Eigenentwicklungen des jeweiligen Herstellers er- 
setzt wurde. Dies führte für den Anwender zu einer eher verwirrenden Auswahl an 
verschiedenen Bediensystemen, die alle unterschiedlich aussahen, im Grunde je- 
doch identisch waren. 


Im Juli 1988 führte OSF eine Technologieausschreibung, ein Request for Techno- 
logy (RFT), für grafische Bediensysteme durch. Grundvoraussetzung dieses RFT 
war, daß das System auf dem X Window System aufbauen sollte. Im Januar 1989 
gab OSF die Ergebnisse des RFT bekannt. Ausgewählt wurden das Toolkit und die 
User Interface Language (UIL) von DEC, die Toolkiteinbindung, der Fensterver- 
walter und der 3-D Look von HP sowie das Look and Feel des Presentation Mana- 
ger von Microsoft. Das Ergebnis erhielt den Namen Motif. 


Mit OSF/Motif erhält der Entwickler eine gemeinsame, portable Programmier- 
schnittstelle (API - Application Programming Interface) auf einer Vielfalt von 
Hardwareplattformen (VAX, SPARC, MIPS, Intel, Motorola) und im Grunde ge- 
nommen auf allen Systemen, die X Window unterstützen. 
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OSF/Motif-Anwendung 


X Window System 
SINIX-Betriebssystem 


Abbildung 4-1: OSF/Motif-Anwendungen benutzen die Dienste, die OSF/Motif, X Window und das SINIX-Betriebs- 
system anbieten. 


Das Erscheinungsbild einer Anwendung, die auf OSF/Motif basiert, ähnelt einer auf 
MS-Windows basierenden Anwendung. Dies ermöglicht dem Anwender einen glei- 
tenden Übergang von PC-basierten Systemen auf SINIX-Systeme. Auch wenn der 
Entwickler seinen MS-Windows- oder OS/2-Code nicht direkt übernehmen kann, 
kann zumindest das Erscheinungsbild des Programms mit minimalen Änderungen 
übernommen werden. Da auf dem X Window System aufgesetzt worden war, wurde 
für OSF/Motif- und OSF/Motif-basierte Anwendungen leichte Portierbarkeit er- 
reicht. Da X Window sehr portabel und auf einer breiten Palette von Systemen ver- 
fügbar ist, konnte sich OSF/Motif schnell weit verbreiten. Neben seiner Verfügbar- 
keit unter UNIX wird OSF/Motif von etwa 38 Betriebssystemen unterstützt, 
darunter OS/2, MS-Windows und Macintosh. Natürlich arbeiten OSF/Motif-An- 
wendungen nicht nur mit OSF/Motif zusammen, sondern auch mit dem Betriebssy- 
stem, so daß hier der problemlosen Portierbarkeit von OSF/Motif-Anwendungen 
Grenzen gesetzt sind. 


4 Benutzerumgebung 


OSF/Motif Elemente 


OSF/Motif besteht aus drei Hauptelementen, dem Toolkit, der User Interface Lan- 
guage (UIL) und dem Fensterverwalter. 


Toolkit 


OSF/Motif bietet dem Entwickler ein standardisiertes Toolkit mit 30 Widgets und 
sechs Gadgets. Da die OSF/Motif Widgets auf Basis der Xt Intrinsics (MIT) erstellt 
wurden, können Software-Entwickler dem System spezielle Widgets für besondere 
Aufgaben nahtlos hinzufügen. 


UIL 


Mit der User Interface Language kann das Bediensystem eines Programms be- 
schrieben werden, ohne daß dessen eigentliche Funktionen bekannt sind. Zusätzlich 
wird die UIL dazu verwendet, festzulegen, welche Funktionen eines Programms als 
Reaktionen auf bestimmte Aktionen des Anwenders ausgeführt werden. Aus dieser 
Beschreibung erstellt der UIL-Compiler eine Ressourcendatei, die vom Programm 
geladen wird. 


Fensterverwalter 


Der OSF/Motif Fensterverwalter legt einen Rahmen um die einzelnen Fenster, mit 
dem die Fenster jeweils verschoben oder in ihrer Größe verändert werden können. 
Der Fensterverwalter richtet sich dabei nach der Funktionalität von MS-Windows 
oder Presentation Manager (OS/2). Zu einem Sinnbild (Icon) verkleinerte Fenster 
werden in einem speziellen Iconfenster angezeigt. 
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SINIX/windows 


SINIX/windowsgliedert sich in zwei Bestandteile: das SINIX/windows User Envi- 
ronment (SUE) und SINIX/windows Development (SD). SD ist mit der sogenann- 
ten OSF/Motif Validation Test Suite getestet worden und hat das Gütesiegel „OSF/ 
Motif Validated” erhalten. 


SINIX/windows User Environment 
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SUE bietet dem Anwender einen komfortablen elektronischen Schreibtisch zur Be- 
dienung des Betriebssystems und eigener Anwendungen. Zusätzlich wird dem An- 
wender umfangreiches Zubehör angeboten, das ihn bei der Einrichtung einer effek- 
tiveren Arbeitsumgebung unterstützt. Im einzelnen besteht das SUE aus folgenden 
Komponenten: dem OSF/Motif Runtime-System, einem elektronischen Schreib- 
tisch, dem Desktop, Konfigurationshilfen zur benutzerspezifischen Anpassung und 
einem Hypertext-ähnlichen Online-Hilfesystem. OSF/Motif bietet ein Bediensy- 
stem, dessen Erscheinungsbild und Bedienbarkeit MS-Windows ähnelt. Dadurch 
verfügen Anwender über ähnliche Bediensysteme auf SINIX-Systemen und MS- 
Windows-Systemen. Die Fenstertechnik ermöglicht das gleichzeitige Arbeiten mit 
mehreren Anwendungen. So wird bei der Bearbeitung komplexer Vorgänge Zeit ge- 
spart. Zusätzlich stehen Oberflächenobjekte eines Bediensystems wie Buttons, Pull- 
down-Menüs oder Pop-up-Menüs zur Verfügung. Die Cut-Copy-Paste-Funktionali- 
tät ermöglicht dem Anwender, beliebige Texte oder Symbole zu markieren, sie tem- 
porär zu speichern und an einer anderen Stelle wieder einzufügen. So werden dem 
Anwender mühselige Tastatureingaben erspart und Tippfehler vermieden. 
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Abbildung 4-2: Moderne grafische Bediensysteme wie SINIX/windows stellen dem Anwender einen komfortablen 
elektronischen Schreibtisch zur Betriebssystembedienung und für seine eigenen Anwendungen zur Verfügung. 


Mit dem Desktop können häufig wiederkehrende Bedienvorgänge mit der Maus 
grafisch interaktiv ausgeführt werden. Dies ersetzt komplexe Eingaben über die 
Kommandozeile der Shell. Beliebige Anwendungen können interaktiv in den Desk- 
top eingebunden oder neue Dateitypen definiert werden. Diese werden visuell durch 
Symbole (für Dateien und Dateiverzeichnisse) und Icons (für Programme) reprä- 
sentiert. So können Anwendungen einfach entweder durch Doppelklick mit der 
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Maus auf das entsprechende grafische Symbol oder mittels der sogenannten „Drag 
and Drop“-Funktion aufgerufen werden. Drag and Drop bedeutet, daß das grafische 
Symbol für eine Datei mit der Maus zu der dazugehörigen Anwendung gezogen 
wird (engl. to drag) und dort abgelegt wird (engl. to drop), so daß die Anwendung 
mit dem aktuellen Dokument direkt gestartet oder eine bereits laufende Anwendung 
mit neuen Daten versorgt wird. 


Der Anwender kann seinen eigenen Desktop selbst interaktiv einrichten, indem er 
eigene Werkzeuge oder eigene Dateitypen definiert. Darüber hinaus kann der Sy- 
stemverwalter den Standard-Desktop über eine umfangreiche Konfigurationsspra- 
che an die individuellen Anforderungen des Anwenders anpassen. 


Für die gesamte Bedienoberfläche des Desktop steht ein hypertext-ähnliches Hilfe- 
system über die Menüfunktion Hilfe zur Verfügung. Hypertext-ähnlich bedeutet in 
diesem Zusammenhang, daß Hilfefenster so angeordnet sind, daß der Anwender 
sich jeweils detailliertere Informationen zu einem speziellen Thema anzeigen lassen 
kann, indem er ein hervorgehobenes Wort anklickt. Der Anwender kann so jederzeit 
kontextsensitive Hilfe-Informationen erhalten. Er klickt mit der Maus auf ein be- 
stimmtes Thema (entweder ein Symbol im Fenster oder einen Menüeintrag) und der 
entsprechende Hilfetext erscheint sofort. Das heißt, es muß kein Index zur Hilfe- 
Dokumentation benutzt werden, um die Information zum aktuellen Problem zu fin- 
den, sondern die benötigte Hilfe kann direkt im Zusammenhang mit dem aktuellen 
Arbeitsvorgang abgefragt werden. Unter SUE wird das Arbeiten mit OSF/Motif 
durch Anwenderfunktionen zur SINIX-Systembedienung erleichtert. Diese Anwen- 
derfunktionen, die in Form leicht verständlicher Icons visualisiert werden, bestehen 
aus einer Reihe von Werkzeugen. 
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Das Symbol Desktop-Verwalter ermöglicht dem Anwender, Symbole für alle häufig 
benötigten Programme oder Werkzeuge ständig sichtbar auf dem Bildschirm zu ha- 
ben. Alle anderen Dateien und Programme sind über den Dateiverwalter verfügbar, 
der diese grafisch repräsentiert. Alle Werkzeuge, die nicht standardmäßig auf dem 
Desktop liegen, aber jederzeit aufrufbar sind, befinden sich im Werkzeugkatalog. 
Von dort aus kann der Anwender sie bei Bedarf starten oder die Drop-and-Drag- 
Funktion der Maus benutzen, um sie auf seinen eigenen Desktop zu bewegen. Da 
der Desktop eine Anwendung ist, die auf OSF/Motif und dem X Window System 
basiert, kann der Anwender mit Hilfe des OSF/Motif-Ressource-Editors Voreinstel- 
lungen wie Farbe, Schriftart und Anordnung festlegen. 


Mit Hilfe der Funktion /nfo+Dienste können jederzeit Informationen über die Ar- 
beitsumgebung, wie etwa über installierte Software, Plattenbelegung, Rechneraus- 
lastung und laufende Prozesse abgefragt werden. Auch Standard-Einstellungen wie 
das Paßwort, der verwendete Texteditor oder die Sprache, in der der Anwender mit 
dem System kommuniziert, können individuell von ihm selbst verändert werden. 
Neben dem Werkzeug „Manuale“, das dem Anwender den Zugriff auf die Online- 
Dokumentation ermöglicht, stehen z.B. noch eine analoge Uhr und ein Taschen- 
rechner zur Verfügung. Mit dem Produkt werden verschiedene Editoren als Werk- 
zeuge für den Anwender geliefert. Hierzu gehören verschiedene Texteditoren und 
der Ressource-Editor, der der Abfrage oder der komfortablen Änderung von OSF/ 
Motif-Ressourcen dient. Mit Hilfe des Bitmap-Editors können grafische Symbole 
erzeugt werden, die beispielsweise benötigt werden, wenn benutzereigene Anwen- 
dungen in den Desktop integriert werden sollen. Ein Pixel-Editor unterstützt farbige 
Icons, da das SINIX/windows User Environment sowohl mit schwarz/weißer als 
auch mit farbiger Bedienoberfläche zur Verfügung steht. 
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Abbildung 4-3: Das SINIX/windows User Environment ermöglicht die einfache Betriebssystembedienung und 
-verwaltung. 
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SINIX/windows Development Package 


Das SINIX/windows Development Package besteht aus dem OSF/Motif-Develop- 
ment-System sowie Erweiterungen wie beispielsweise Widgets, die zur ursprüngli- 
chen OSF/Motif-Schnittstelle hinzugefügt wurden. Diese Erweiterungen erleich- 
tern die Programmierung kommerzieller Anwendungen, da sich häufig 
wiederholende Prozeduren in Form von vier zusätzlichen Widgets für den Entwick- 
ler vorgegeben sind. Diese vier Widgets von Siemens Nixdorf werden im folgenden 
beschrieben: 


Format-Widget 


Das Format-Widget - abgeleitet vom OSF/Motif Text-Widget - erleichtert die Er- 
stellung von Formaten unter OSF/Motif und steigert damit Produktivität und Kom- 
fort. Durch vordefinierte Feldtypen (numerisch, alphanumerisch, Datum und Zeit) 
wird der Programmieraufwand erheblich verkürzt, da der Entwickler die Feldtypen 
nicht jedesmal neu definieren muß. Bei den Feldwerten können Großbuchstaben au- 
tomatisch in Kleinbuchstaben umgewandelt werden. Für alphanumerische Felder 
kann entweder Eingabemodus oder Überschreibmodus eingestellt werden. Einga- 
befehler werden durch automatische Plausibilitätsprüfungen vermieden. Format- 
Widgets können für Masken aller Art wie beispielsweise für Personalbögen, Auf- 
tragsbearbeitung, Kundenkarteien oder zur Terminüberwachung verwendet wer- 
den. 


Tabellen-Widget 


Der Entwickler kann auf einfache Weise Daten in Form von Tabellen darstellen; die 
Tabellen sind mit horizontalen und vertikalen Rollbalken versehen. Verschiedene 
Attribute können als Tabelleneigenschaften festgelegt werden: Schriftfamilien, An- 
zahl der Zeilen/Spalten, Feldausrichtung (linksbündig, rechtsbündig, zentriert), der 
Zellentyp oder die Editierbarkeit von Spalten. Zum Bearbeiten des Tabellen-Widget 
wird häufig das Format-Widget benutzt. Das Tabellen-Widget kann auch zur Dar- 
stellung großer Datenmengen verwendet werden (z.B. 10 000 Dateneinträge). 


Hilfe-Widget 


Help-Callback-Listen sind Bestandteil der Standard-Widgets von OSF/Motif. Der 
Hauptaufwand beim Erstellen von Hilfetexten verbleibt jedoch beim Entwickler: 
Festlegen des Kontexts im Programm, Auffinden des richtigen Hilfetexts im Fen- 
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ster, usw. Um den Aufwand zur Erstellung hypertext-ähnlicher Hilfe-Informationen 
drastisch zu reduzieren, bietet Siemens Nixdorf das Hilfe-Widget an. Die Unterstüt- 
zung des Anwenders durch kontextsensitive Hilfe ist ein wesentliches Merkmal er- 
gonomischer Bediensysteme. Das Hilfe-Widget stellt dem Entwickler eine vordefi- 
nierte Hilfe-Struktur zur Verfügung, die er nur noch mit den dazugehörigen 
Objekten auf der Bedienoberfläche verknüpfen und mit den entsprechenden Hilfe- 
texten füllen muß. 


Für den Anwender erscheint ein Hilfetext immer in einem eigenen Fenster. Falls der 
Bereich für die Anzeige nicht ausreichend ist, wird automatisch ein Rollbalken hin- 
zugefügt. Im Hilfefenster stehen immer die Buttons Ende, Zurück, Bleib und Hilfe 
zur Verfügung. Mit Hilfe des Buttons Zurück springt das System in der Hierarchie 
der ausgewählten Querverweise um eine Stufe zurück, so daß ohne weiteren Pro- 
grammieraufwand ein automatischen Blättern im Hilfetext möglich ist. Der Toggle- 
Button Bleib legt fest, ob der gerade sichtbare Hilfetext vom nächsten Hilfetext 
überschrieben wird oder nicht. Querverweise sind durch Fettdruck hervorgehoben 
und werden durch Anklicken aktiviert. Falls für ein Objekt kontextsensitive Hilfe 
angeboten wird, wandelt sich die Cursor-Form in ein Fragezeichen und durch An- 
klicken dieses Objekts in der Anwendung wird der zugehörige Hilfetext angezeigt. 


Browser-Widget 


Das Browser-Widget ermöglicht die Darstellung von Symbolen und Texten in ei- 
nem Fenster mit der Option, einzelne oder mehrere Elemente auszuwählen und zu- 
zuordnen. Eine mögliche Anwendung dieses Widgets ist ein elektronischer Schreib- 
tisch (wie etwa der SINIX/windows Desktop), in dem Dateien oder 
Dateiverzeichnisse als Icons angezeigt werden. Das Browser-Widget bietet Funk- 
tionen zum Einfügen, Löschen und Verschieben von Einträgen. 


Siemens Nixdorf Styleguide 
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Der Siemens Nixdorf Styleguide besteht aus einer Regelsammlung, die das „Look 
and Feel” von Bediensystemen beschreiben. Diese bilden die Basis für einen kon- 
sistenten und ergonomisch korrekten Ansatz für Bedienoberflächen. Eine gute Be- 
dienoberfläche ist einfach zu handhaben. Doch gerade die Einfachheit solcher Be- 
dienoberflächen verlangt große Sorgfalt im Erstellungsprozeß und verbirgt häufig 
ein komplexes Design. Eine Programmierschicht allein (z.B. Motif) läßt oft zu vie- 
les ungenau, um eine gute Bedienoberfläche zu garantieren. 
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Notwendig sind präzise Richtlinien für das Layout und die Bedienabläufe der Ele- 
mente eines Bediensystems. Je detaillierter diese Richtlinien sind, umso mehr wird 
der Entwickler von der Last des Designs der Bedienoberfläche befreit. Der Siemens 
Nixdorf Styleguide enthält solche Richtlinien, die durch zahlreiche Beispiele ver- 
deutlicht werden. Der Siemens Nixdorf Styleguide kann sowohl bei der Entwick- 
lung neuer Bedienoberflächen als auch bei der Weiterentwicklung bestehender Be- 
dienoberflächen angewandt werden. Er beinhaltet zudem wertvolles 
Übungsmaterial für den Anwender, da sich eine Vielzahl von Bediensystemen in ih- 
rem Erscheinungsbild und ihren Bedienabläufen so verhalten, wie im Siemens Nix- 
dorf Styleguide beschrieben. 


Dialog Builder 


Die Programmierung eines Bediensystems direkt in C unter Verwendung der be- 
schriebenen X Window- und OSF/Motif-Schnittstellen erfordert viel Erfahrung und 
Fingerspitzengefühl im Umgang mit Bedienoberflächen. Das Design einer Bedien- 
oberfläche ist ein äußerst wichtiger Aspekt der Software, da die Akzeptanz eines 
Software-Produkts wesentlich vom Design der Bedienoberfläche abhängt. Aus die- 
sem Grund wurde die Entscheidung getroffen, das Werkzeug Dialog Builder als in- 
teraktive Hilfe zur Erstellung von SINIX-Bedienoberflächen anzubieten. 


Der Dialog Builder basiert auf SINIX/windows Development und kann dazu be- 
nutzt werden, OSF/Motif-Bediensysteme zu erstellen, die konform zum Styleguide 
sind. Mit dem Dialog Builder können sowohl das Layout als auch die Dialogabläufe 
eines Bediensystems auf einem grafisch interaktiven Weg erstellt werden. Widgets 
von Siemens Nixdorf können ebenfalls mit dem Dialog Builder bearbeitet werden. 


Abbildung 4-4 zeigt die Architektur des Dialog Builder. Der rechte Teil des Abbil- 
dung stellt die interaktive Entwicklungsumgebung dar, die auf SINIX und OSF/Mo- 
tif basiert. Die Laufzeitumgebung für fertiggestellte Bediensysteme ist im linken 
Teil der Abbildung skizziert. Der Dialog Builder wurde so konzipiert, daß die damit 
entwickelten Bediensysteme sowohl unter OSF/Motif als auch unter MS-Windows 
ablauffähig sind. 
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Dialog Builder 
Laufzeitsystem C-Code 


Dialogbeschreibung 


Dialog-  |Dialog- — 
Layouteditor) Ablaufeditor Bibliotheken 


Abbildung 4-4: Der Dialog-Builder 


Der grafische Layout-Editor, der nach dem WYSIWYG Prinzip (What You See Is 
What You Get) arbeitet, ermöglicht dem Entwickler eine statische Anordnung des 
Bildschirmlayouts, z.B. der Lage und Größe von Fenstern und Buttons. Das dyna- 
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mische Verhalten der Bedienoberfläche, wie beispielsweise die Reaktion auf das 
Aktivieren eines Buttons, wird im Dialogablaufeditor festgelegt. Durch Simulation 
kann das erstellte Bediensystem zu einem frühen Zeitpunkt getestet werden. 


Die Anbindung eines mit dem Dialog Builder erstellten Bediensystems an die ei- 
gentliche Anwendung erfolgt entweder über ein Laufzeitsystem oder über die vom 
Codegenerator erzeugten C-Module. Bei Verwendung des Codegenerators werden 
die C-Module des Bediensystems und die Module der Anwendung kompiliert und 
gebunden. Bei Verwendung des Laufzeitsystems werden spezielle Laufzeitmodule 
mit dem Anwendungscode gebunden. Während die Anwendung abläuft, liest das 
Laufzeitsystem die Dialogbeschreibung ein, erzeugt die entsprechenden Dialogob- 
jekte und interpretiert die vorher erzeugten Dialogablaufskripts. Wie in Abbildung 
4-4 skizziert, steht sowohl für OSF/Motif als auch für MS-Windows ein Laufzeit- 
system zur Verfügung. 


Wiederverwendbarkeit und Standardisierung von Bedienoberflächen werden im 
Dialog Builder durch ein Bibliothekskonzept unterstützt. Diese Bibliotheken beste- 
hen aus Sammlungen vorgefertigter Module von Dialogobjekten. Die Bibliotheken 
können mit Hilfe eines Browsers durchsucht werden. Einzelne Objekte können 
dann ausgewählt und in das zu erstellende Bediensystem kopiert werden. 


Die Bibliothek des Siemens Nixdorf Styleguides enthält Muster für alle Dialogob- 
jekte, die im Siemens Nixdorf Styleguide beschrieben sind. Bei Verwendung dieser 
Bibliotheken wird die Konformität der erstellten Bedienoberfläche ebenso garan- 
tiert wie die Portabilität zwischen OSF/Motif und MS-Windows. Die OSF/Motif- 
Bibliothek enthält alle von OSF/Motif angebotenen Dialogobjekte. Der Entwickler 
einer Bedienoberfläche kann bei der Arbeit mit dem Dialog Builder auch auf diese 
Bibliotheken zugreifen. 


Unter Zuhilfenahme der Objekte aus diesen Bibliotheken kann der Entwickler die 
von ihm gewünschte Bedienoberfläche interaktiv zusammensetzen. Reaktionen auf 
Eingaben des Anwenders werden mit Hilfe einer Dialogablaufsprache im Dialogab- 
laufeditor definiert. 


Bediensysteme, die mit Dialog Builder erstellt wurden, werden in Dialogbeschrei- 
bungs-Dateien im ASCII Format abgelegt. Die Dialogbeschreibung enthält eine 
Layoutbeschreibung und die Dialogsteuerung der Bedienoberfläche. Bedienober- 
flächen, die mit Hilfe des Dialog Builder entwickelt wurden, können über die NLS- 
Funktionalität an unterschiedliche landessprachliche Umgebungen angepaßt wer- 
den. 
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Daneben ist im Dialog Builder ein Dialogsimulator enthalten, mit dem der erstellte 
Dialogablauf ausgeführt und sofort überprüft werden kann. Der Dialogsimulator 
verfügt über eine Trace-Funktion, die die Überprüfung der erstellten Ablaufskripts 
wesentlich erleichtert. 


Aus den Dialogbeschreibungen kann bei Bedarf auch C-Code erzeugt werden. Da- 
bei können sowohl das Layout als auch die Ablaufsteuerung in den C-Code mitein- 
bezogen werden. Die aus dem C-Code generierbare Anwendung ist auch ohne das 
Laufzeitsystem des Dialog Builder ablauffähig, so daß eine problemlose Portierung 
auf andere Plattformen ermöglicht wird. 


XVision (MS-Windows) 
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X Vision ermöglicht dem PC-Anwender von MS-Windows 3.1 oder einer neueren 
MS-Windows-Version, an einem Bildschirm gleichzeitig in der PC-Welt und in der 
UNIX-Welt zu arbeiten. Realisiert wird dies über eine X-Terminal-Emulation unter 
MS-Windows. Auch zwischen X Window-Anwendungen und MS-Windows-An- 
wendungen (sowie zwischen X Window-Anwendungen) ist die Verwendung der 
Cut-and-Paste-Funktionalität möglich. 


Der PC muß über eine LAN-Karte, die als Ethernet Adapter dient, und TCP/IP 
(LANI)-Software verfügen. (Dies ist abhängig vom Typ des Netzwerks. Auch die 
Verwendung eines Tokenring-Adapters in einem Token Ring-Netzwerk wäre mög- 
lich.) Folgende zusätzliche Hardwarevoraussetzungen sind erforderlich: Ein PC mit 
80386 Prozessor (oder höher) und 4 MB Arbeitsspeicher, eine Maus mit Drei-Ta- 
sten-Funktionalität (für OSF/Motif) sowie ein VGA -Grafikadapter. Die verwendete 
MS-Windows-Version muß MS-Windows 3.1 oder höher sein. Auf dem SINIX- 
Rechner müssen das X Window System und X-Anwendungen installiert sein. 


Im Ein-Fenster-Betrieb hat die X Window-Umgebung ein einziges MS-Windows- 
Fenster. In diesem einen Fenster entsprechen Erscheinungsbild und Bedienung der 
X-Umgebung (OSF/Motif, Open Look). Die Steuerung dieses Fensters erfolgt über 
die Fensterverwalter der X-Umgebung. Im Mehr-Fenster-Betrieb stellt X Vision 
auch eine eigene Fensterverwaltung zur Verfügung, die Erscheinungsbild und Be- 
dienung der Fenster entsprechend dem Standard von MS-Windows-Anwendungen 
ermöglicht. Die lokale Fensterverwaltung von X’Vision ist kompatibel zu OSF/Mo- 
tif. 
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Der Mehr-Fenster-Betrieb bietet hinsichtlich der Rechenleistung klare Vorteile, da 
viele Aktionen wie beispielsweise Mausbewegungen lokal verarbeitet werden kön- 
nen, statt über das Netzwerk zur Auswertung durch den Host-Rechner geschickt zu 
werden. Auf diese Art und Weise werden gleichzeitig der Datenverkehr und die Be- 
anspruchung des Host-Rechners reduziert. 


Alphanumerische Bediensysteme 


FMLI 


Computerzeitschriften favorisieren schon seit langem Systeme mit grafischen Be- 
dienoberflächen. Alphanumerische Terminals machen jedoch noch immer ein be- 
deutendes Segment des Terminalmarkts aus. Auch in näherer Zukunft ist hier keine 
Änderung zu erwarten. Solange die Verwendung eines Terminals auf Aufgaben wie 
Dateneingabe oder Datenanzeige beschränkt ist, ist die Investition in teure grafikfä- 
hige Terminals oft nicht gerechtfertigt. 


SINIX wird auch in Zukunft sowohl alphanumerische als auch grafische Bedien- 
systeme unterstützen. Die ersten SINIX-Systeme verfügten über ein leicht verständ- 
liches alphanumerisches Menü-Bediensystem für Systemverwaltung, Betrieb des 
Computers und die Verwendung individueller Anwendungen. Mit dem Übergang zu 
UNIX SVR4 wurde als Grundlage das alphanumerische Werkzeug zur Entwicklung 
von Bediensystemen von AT&T, FMLI (Form and Menu Language Interpreter), 
gewählt. FMLI ist nun im Betriebssystemumfang von SINIX enthalten. 


Die Funktionalität des Bediensystems für Anwender und des Bediensystems zur 
Systemverwaltung wurden aufbauend auf FMLI in die Packages FACE und OA&M 
(Operation, Administration and Maintenance) implementiert. Zur Entwicklung al- 
phanumerischer Bediensysteme wird von Siemens Nixdorf ein Satz von Werkzeu- 
gen, XMS, angeboten. 


Bei FMLI (Form and Menu Language Interpreter) handelt es sich um ein Werk- 
zeug, das es dem Anwendungsentwickler ermöglicht, für unterschiedliche Anwen- 
dungen alphanumerische Bedienoberflächen zu erstellen. Auf FMLI basierende Be- 
dienoberflächen bestehen meist aus Menüs, Masken und Textfenstern, die der 
Anwendungsentwickler in einer speziell für diesen Zweck verfügbaren Sprache be- 
schreibt. Diese Sprache, (FML — Form and Menu Language), erlaubt dem Ent- 
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wickler, Inhalt, Größe, Lage und viele andere Charakteristika der Bildschirmobjek- 
te ebenso wie Aktionen zu programmieren. Diese Aktionen werden durch 
bestimmte Eingaben des Anwenders ausgelöst. Die Sprache FML verbindet sowohl 
deskriptive als auch prozedurale Elemente der Programmierung von Bedienoberflä- 
chen. 


FMLI wertet die Menübeschreibungen, Formatbeschreibungen und Beschreibun- 
gen für Textfenster aus und gibt diese auf dem Bildschirm aus. Darüber hinaus steu- 
ert FMLI den gesamten Dialogablauf. FMLI leitet die Bewegung innerhalb der Me- 
nüs und zwischen verschiedenen Bildschirmobjekten ebenso wie die Erstellung und 
Positionierung neuer Objekte. FMLI bietet neben der Anzeige von Menüs, Formu- 
laren und Textfenstern die Möglichkeit, Ausgaben in einer Meldungszeile anzuzei- 
gen und Kommandos von einer zu diesem Zweck freigehaltenen Kommandozeile 
einzulesen. Häufig benötigte Funktionen können über zusätzliche Funktionstasten 
ausgeführt werden. 


Der auswertende Ansatz von FMLI eröffnet die Vorteile eines kurzfristigen Proto- 
typeinsatzes und einfacher Wartung. Ab der Version SINIX V5.41 wurde FMLI von 
Siemens Nixdorf in Zusammenarbeit mit USL internationalisiert, d.h. Anwendun- 
gen können in sprachunabhängiger Form kodiert werden. Meldungen und Texte 
werden zur Laufzeit der Anwendung aus Sprachkatalogen oder speziellen Dateiver- 
zeichnissen eingelesen. Eine Anwendung muß so nur einmal programmiert werden 
und kann leicht an andere Sprachen angepaßt werden, indem lediglich die Kataloge 
oder Texte übersetzt werden. Die Internationalisierung von FMLI durch Siemens 
Nixdorf wurde in SVR4 integriert und ist nun Bestandteil der Hauptlinie von SVR4, 
das von USL an UNIX-Lizenznehmer geliefert wird. 


FACE (Framed Access Command Environment) ist ein menügesteuertes Bediensy- 
stem für SINIX-Systeme. FACE basiert auf FMLI, das Menüs und Bildschirmmas- 
ken für alphanumerische Terminals zur Verfügung stellt. Dadurch ist FACE auf al- 
len Terminals ablauffähig und nicht auf grafikfähige Bildschirme beschränkt. Die 
Originalversion von FACE ist eine Komponente von UNIX SVR4, die von USL ge- 
liefert wird. Auch diese FACE-Version wurde 1991 von Siemens Nixdorf in Zusam- 
menarbeit mit USL parallel zu FMLI internationalisiert. FACE 4.2 baut auf dieser 
internationalisierten Version auf und beinhaltet zusätzliche funktionale Erweiterun- 
gen durch Siemens Nixdorf (Postdienste, Unterstützung externer Speichermedien 
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wie Disketten, Magnetbandkassetten und CD-ROM sowie weitere kleinere Funk- 
tionen). Die derzeit gültige Version FACE 4.3 ist in einer deutschen und einer eng- 
lischen Version erhältlich. 


Über diese Bedienoberfläche können sehr unterschiedliche und häufig anfallende 
Funktionen ausgeführt werden. Der Anwender muß lediglich über geringe Kennt- 
nisse des Betriebssystems SINIX verfügen. Alle Operationen werden von FACE 
über Fenster ausgeführt. Der Anwender erhält während des Programmablaufs An- 
weisungen und kann sich bei Bedarf über die aktuelle Funktion oder das aktuelle 
Fenster einen Hilfetext ausgeben lassen. 


Nach dem Starten von FACE erhält der Anwender ein Menü, von dem aus er andere 
Menüs und Fenster öffnen kann. Diese werden auf dem Bildschirm ähnlich wie un- 
ter X Window, OSF/Motif oder MS-Windows in Überlappungstechnik präsentiert. 
Der Anwender kann unterschiedliche Aufgaben erledigen, indem er zwischen den 
Fenstern wechselt. Eine simultane Ausführung mehrerer Prozesse in unterschiedli- 
chen Fenstern ist jedoch nicht möglich. 


FACE Systemverwalter OA&M Ä 
FMLI 
| Terminal 


Abbildung 4-5: FACE 
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XMS 


Das strategische Werkzeug von Siemens Nixdorf zur Erstellung alphanumerischer 
Bediensysteme ist XMS. XMS besteht aus einem reichhaltigen Angebot an Werk- 
zeugen: 


Layout-Editor 


Der nach dem WYSIWYG-Prinzip arbeitende Layout-Editor unterstützt die Struk- 
turierung von Bildschirmlayouts. Von ihm hängt die Bildschirmdarstellung ab. Zu- 
sätzlich zur Geometrie einzelner Bildschirme kann der Entwickler hier auch die 
Bildschirmattribute (z.B. Formate) und Plausibilitätsregeln für Bildschirmfelder de- 
finieren. 


Hilfetext-Editor 


Hilfe- und Meldungstexte werden unter Verwendung des Hilfetext-Editors erstellt 
und bestimmten Feldern zugewiesen. Innerhalb dieser Texte können Platzhalter für 
Ersatzzeichenketten verwendet und Textbausteine mit Attributen versehen werden. 
Hilfetexte können auch verkettet und als Auswahllisten benutzt werden. 


Dialog-Simulation 


Mit diesem Simulationswerkzeug können Masken getestet werden, noch bevor das 
Anwendungsprogramm geschrieben ist. So können verschiedene Masken zu Test- 
abläufen des Bediensystems verkettet werden. 


Programmierung 


Um die Programmiersprachen C und COBOL unterstützen zu können, verfügt XMS 
über eine Ein-/Ausgabesprache. Die Kommandos dieser Sprache sind nach SQL- 
Syntax aufgebaut. Sie sind für beide Programmiersprachen gleich und werden von 
einem Precompiler, der der jeweiligen Sprache vorgeschaltet ist, in sprachspezifi- 
sche Aufrufe umgesetzt. 
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Ablaufbibliotheken 


Die XMS Bibliotheken werden mit der Anwendung zusammengebunden, können 
aber auch als gemeinsam genutzte Bibliothek dynamisch dazugebunden werden. 
Sie führen Ein- und Ausgabe entsprechend der Formularbeschreibung durch und 
übernehmen die Behandlung der Hilfetexte und Meldungen. 


AlphaWindow 


Systeme mit Fenstertechnik werden seit Jahren benutzt, um auf grafikfähigen Bild- 
schirmen eine produktive Benutzerumgebung anzubieten. Standards wie X Win- 
dow, OSF/Motif oder MS-Windows sind mittlerweile fest etabliert. 


Das Ziel, deren Vorteile auch auf alphanumerischen Bildschirmen zu nutzen, konnte 
bisher leider nicht verwirklicht werden, da kein angemessener Standard verfügbar 
war, der bei guter Leistung ausreichende Funktionalität bot. Ein Fenstersystem für 
alphanumerische Bildschirme, das ausschließlich mit Mitteln der Software realisiert 
ist, muß unweigerlich an eingeschränkter Leistungsfähigkeit scheitern. Alphanume- 
rische Bildschirme werden im allgemeinen über vergleichsweise langsame serielle 
Leitungen an Host-Systeme angeschlossen. Bei einer reinen Softwarelösung ist der 
Datenverkehr, der für die Fensterverwaltung notwendig ist, so groß, daß die Gren- 
zen der Übertragungsleistung schon bald erreicht sind. 


Durch die Gründung der Display Industry Association (DIA), eines Zusammen- 
schlusses der wichtigsten Bildschirmhersteller, wurde ein Neuansatz versucht. Seit 
Januar 1991 versucht die DIA, einen neuen Standard für alphanumerische Bild- 
schirme, die die Fenstertechnik unterstützen, zu definieren. Bereits nach einem Jahr 
konnte als Ergebnis die Spezifikation des AlphaWindow-Terminals (AW) präsen- 
tiert werden. Die ersten Bildschirme, die dieser Spezifikation entsprechen, sind seit 
Ende 1992 auf dem Markt verfügbar. 


Der Aufbau von AlphaWindow sieht vor, daß ein Display Server im Bildschirm alle 
Funktionen übernimmt, die für die Fensterverwaltung notwendig sind, wie etwa das 
Begrenzen und Speichern von Fensterinhalten. Ein Fensterverwalter auf dem Host- 
Rechner stellt die Benutzerschnittstelle zur Verfügung und ermöglicht das Öffnen, 
Schließen und Verändern von Fenstern. Insoweit entspricht das Konzept dem 
X Window System. Im Gegensatz zu X wird die Terminalkommunikation mittels 
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sogenannter virtueller Terminals in der Firmware realisiert. Dadurch wird die Lei- 
stungsfähigkeit zusätzlich verbessert. Im AlphaWindow Standard ist die Mausun- 
terstützung ebenfalls integriert. 


Die DIA ging bei der Festlegung ihres Standards auf ähnliche Weise wie das X- 
Konsortium vor. Der Standard definiert lediglich die Bildschirmschnittstelle und die 
Low-Level Programmierschnittstelle. Bildschirmhersteller können AlphaWindow 
durch ihre eigenen Erweiterungen ergänzen, z.B. durch Terminal-Emulationen, 
Softwarehäuser können Fensterverwalter und Toolkits entwickeln und zuliefern. 


Die DIA empfiehlt eine AlphaWindow-Architektur, die für die Software-Schnitt- 
stelle vier Schichten festlegt: 


Das AlphaWindow-Terminalprotokoll beschreibt die physikalische Termi- 
nalschnittstelle (Low-Level Control-Sequenzen). 


Das AlphaWindow-Anwendungsprotokoll legt fest, wie Anwendungen das Ter- 
minalprotokoll benutzen sollen, um mit dem Terminalprotokoll und dem Fen- 
sterverwalter kommunizieren zu können. Diese Schicht ist die Basis für höhere 
Software-Schichten, Toolkits, Fensterverwalter und Anwendungen, die eine 
Low-Level-Schnittstelle benötigen. Das Anwendungsprotokoll stellt eine ge- 
meinsame Grundlage für alle Software-Hersteller dar. Es garantiert, daß die 
Fensterverwalter und Anwendungen verschiedener Anbieter problemlos neben- 
einander auf einem AlphaWindow-Terminal ablaufen können. 


Die Programmierschnittstelle von AlphaWindow, AlphaWindow Application 
Programming Interface (API), definiert die C-Schnittstelle für das 
Anwendungsprotokoll. Dieses umfaßt alle Funktionen, die für den Zugriff auf 
das AlphaWindow-Terminal notwendig sind. Der Entwickler muß sich so nicht 
mit den Details der Control-Sequenzen befassen. Das API enthält zudem Me- 
chanismen zur Ereignisbehandlung. Es ist zu erwarten, daß Softwarehäuser eine 
Implementierung des API in Form einer AlphaWindow Bibliothek (AWlıb) lie- 
fern werden. 


Toolkits anderer Softwarehäuser. In diesem Bereich ist mit der Realisierung von 
Toolkits durch Softwarehäuser auf Basis der AlphaWindow-Bibliothek AWlib 
zu rechnen. Die DIA nimmt an, daß sowohl proprietäre Toolkits als auch Stan- 
dards wie OSF/Motif auf AlphaWindow portiert werden. Dies ist ebenfalls für 
virtuelle Toolkits wie XVT oder die Toolkits von 4GL zu erwarten. 
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Das API sollte so beschaffen sein, daß die AlphaWindow-Bibliothek direkt in An- 
wendungen eingebunden werden kann oder Anwendungen über den Fensterverwal- 
ter auf das AlphaWindow-Terminal zugreifen können. Um beiden Anforderungen 
zu genügen, müßte die AlphaWindow-Bibliothek einen Multiplexer enthalten. Die- 
ser ermöglicht den Ablauf mehrerer Anwendungen auf einem Terminal. Da derzeit 
eine Arbeitsgruppe der DIA am API arbeitet, sind Änderungen an diesem Konzept 
absehbar. 


Die Zielgruppe für den Einsatz von AlphaWindow bilden Anwender, die die Vortei- 
le des Mehr-Fenster-Betriebs sowie Multi-Tasking und Mausunterstützung nutzen 
wollen, für eigentliche Grafikanwendungen jedoch keinen Bedarf haben. Der 
Hauptvorteil von AlphaWindow besteht in der Möglichkeit, unterschiedliche alpha- 
numerische Anwendungen unverändert in einer OSF/Motif-ähnlichen Umgebung 
ablaufen zu lassen, ohne daß höhere Kosten für X-Terminals und Netzwerke entste- 
hen. 


Internationalisierte Benutzerumgebung 


Das Betriebssystem SINIX basierte bisher ebenso wie die meisten UNIX-Systeme 
auf dem ASCII-Zeichensatz und dem amerikanischen Englisch als der Sprache, mit 
der der Anwender mit dem Computer kommunizieren konnte. Im kommerziellen 
Bereich mußten natürlich schon interaktive Anwendungen in der Sprache des je- 
weiligen Anwenders angeboten werden (Sprache umfaßt in diesem Sinn auch natio- 
nale und kulturelle Konventionen wie beispielsweise Währungsformate). 


Mit großem Aufwand wurden deshalb sogenannte Ländervarianten eines Anwen- 
dungsprogrammes produziert. Für jede Sprachvariante waren eine Anpassung der 
Source, neues Kompilieren usw. erforderlich. 


Die zunehmende internationale Verbreitung von UNIX erforderte jedoch eine Er- 
weiterung des Systems, die den länderspezifischen Eigenheiten und den Gewohn- 
heiten der unterschiedlichen Anwender auf flexiblere Weise gerecht wird. Um die- 
ses Ziel zu verwirklichen, begann X/Open 1986 mit der Arbeit an der Definition des 
NLS (Native Language System). 
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SINIX-Systeme stellen die notwendigen Mittel (Standard-Internationalisierungs- 
funktionen, usw.) zur Erstellung internationalisierter Programme zur Verfügung. Zu 
einem großen Teil handelt es sich schon bei den SINIX-Standard-Kommandos (in- 
klusive der Shell) um internationalisierte Programme. 


Zur Beschreibung der SINIX-Programmierwerkzeuge, die die Internationalisierung 
unterstützen siehe Abschnitt “SINIX APT” auf Seite 77. 
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Überblick 


Die Entwicklungsumgebung stellt die „Werkstatt“ des Programmierers dar, und die 
verschiedenen Tools sind seine Werkzeuge. Der Programmentwickler benötigt in 
den Phasen des Entwurfs, der Implementierung und des Testens sehr unterschiedli- 
che Werkzeuge. Während der Entwurfsphase übernehmen die Designwerkzeuge die 
wichtige Aufgabe, verschiedene Abstraktionsebenen zu verwalten und zu visuali- 
sieren, sowie die Beziehung zwischen den Ebenen herzustellen. In der Implemen- 
tierungsphase verwendet der Programmierer Editoren, um Programme zu entwik- 
keln und Compiler, um sie in die Maschinensprache zu übersetzen. Über die 
Programmiersprachen wird dem Programmierer eine über alle SINIX-Systeme ein- 
heitliche Schnittstelle (API) zur Verfügung gestellt. Damit er mit den Änderungen 
auf dem Laufenden bleibt und um die Kontrolle darüber zu behalten, welche Ver- 
sionen seines Programms kompiliert wurden, braucht der Programmierer ein Kon- 
figurations-Managementsystem. Während der Implementierung und in der Testpha- 
se verwendet der Programmierer einen Debugger. Der Debugger versetzt ihn in die 
Lage, ein Programm zur Ausführungszeit zu überwachen, sei es durch schrittweise 
Verfolgung oder durch die situationsbedingte Darstellung von Zwischenergebnis- 
sen. 


Dieses Kapitel behandelt alle genannten Werkzeuge. Zuerst werden die Program- 
miersprachen, die Compiler und das SINIX API beschrieben. Danach wird kurz auf 
die Rolle der Editoren, Dienstprogramme, Debugger und des Konfigurations-Mana- 
gements eingegangen. Das Kapitel endet schließlich mit der Beschreibung einiger 
Werkzeuge für das computerunterstützte Software-Engineering (Computer-Aided 
Software Engineering - CASE). 
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Compiler und Programmiersprachen 


Die Evolution der Programmiersprachen in den letzten Jahrzehnten hat zur Schaf- 
fung neuer Sprachmittel geführt, die die Strukturierung des Kontrollflusses, ab- 
strakte Datentypen (Pascal), Modularisierung großer Programme (Ada) unterstüt- 
zen sowie neue Programmierparadigmen, wie die objektorientierte 
Programmierung (C++) und die deklarative Programmierung (PROLOG) geschaf- 
fen haben. Die verschiedenen Programmiersprachen eignen sich für unterschiedli- 
che Zwecke, und das Ziel von Siemens Nixdorf ist es, dem Programmierer eine 
große Auswahl an Programmiersprachen und erstklassige Compilertechnologien 
zur Verfügung zu stellen, damit die Programme in den effizientesten ausführbaren 
Code übersetzt werden können. 


Compilertechnologie 


66 


Jedes Programm, egal in welcher Programmiersprache geschrieben, muß von einem 
Compiler (oder einem Interpreter) in eine Folge von Instruktionen übersetzt wer- 
den, die vom Prozessor des Rechners ausgeführt werden können. Außerdem muß 
das übersetzte Programm in einem Format aufbereitet werden, das vom Binder und 
Lader des Betriebssystems verstanden wird. Das heißt aber auch, daß alle Anwen- 
der von Computerprogrammen von der Qualität und der Effektivität der zur Verfü- 
gung stehenden Compiler profitieren. Compiler sind spezifisch für den Prozessortyp 
und das Betriebssystem des jeweiligen Rechners. 


Die Prozessortechnologie befindet sich in einer rasanten Entwicklung. Im Abstand 
von etwa zwei Jahren kommen neue Mikroprozessoren auf den Markt, die höhere 
Leistungen, enorme Preis-/Leistungsverbesserungen bieten. Dies führt zu einer 
Vielfalt an Prozessorschnittstellen, die untereinander nicht kompatibel sind. Die 
Kunden sollen aber auch in der Lage sein, von dieser Entwicklung zu profitieren, 
ohne ihre Investitionen in Programmentwicklung und -anschaffung zu verlieren. 
Die SINIX-Compiler garantieren dem Benutzer, daß Programm-Sourcen auf allen 
SINIX-Systemen ohne Eingriffe in das Programm zum Ablauf gebracht werden 
können, wenn die im SINIX API definierten Schnittstellen verwendet werden (siehe 
Abschnitt „SINIX APT” auf Seite 75). 
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Die SINIX-Compiler erfüllen die internationalen Standards für die verschiedenen 
Programmiersprachen, ein Anspruch, der von autorisierten Validierungsbehörden 
bestätigt wird. Diese Organisationen haben umfangreiche Prüfprogramme entwik- 
kelt, sogenannte Validation Suites, die nachweisen, daß ein Compiler Programme 
gemäß den Standards verarbeitet. Compiler, die erfolgreich validiert wurden, sind 
dadurch von den Validierungsbehörden zertifiziert. Ein Zertifikat muß für jede Pro- 
zessorlinie, Betriebssystemlinie und Compilerversion neu erworben werden. Die 
SINIX-Compiler werden ständig aktuell valıdiert. 


Sprachspezifische Frontends 


FORTRAN | PascaL | 


Zwischensprache 


HLIL MetaWare 


mel I. le N 


MIPS R3000 MIPS R4000 NSC 32000 i386/486 M68040 | 


Prozessorspezifische Backends 


Abbildung 5-1: Die SINIX-Compilerarchitektur verwendet eine gemeinsame Zwischensprache zur Unterstützung 
einer breiten Palette von Prozessoren und Programmiersprachen. 
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Compiler bestehen in der Regel aus zwei Teilen, dem Frontend und dem Backend. 
Das Frontend ist der sprachabhängige Teil, in dem der eingelesene Programmtext 
analysiert wird. Das Backend stellt den prozessorspezifischen Teil dar, der die vom 
Prozessor ausführbaren Instruktionsfolgen erzeugt. Ein wichtiger Aspekt der Com- 
pilerarchitektur besteht darin, für eine Programmiersprache ein gemeinsames Front- 
end in den verschiedenen SINIX-Compilern einzusetzen und das Backend für einen 
speziellen Prozessor so zu entwickeln, damit es für mehrere Frontends, d.h. für 
mehrere Programmiersprachen, verwendet werden kann. Die Schnittstelle zwischen 
Frontend und Backend wird Zwischensprache genannt. Die einheitlichen Frontends 
gewährleisten, daß auf allen SINIX-Systemen ein gemeinsamer Sprachumfang un- 
terstützt wird. Jeder Hersteller von Compilern hat seine eigene Zwischensprachen- 
Norm. Die Zwischensprachen-Norm der SINIX-Compiler heißt ULS (Universal 
Language System). 


Die Programmiersprache Ada steht in der Tradition der Algol/Pascal-Sprachfami- 
lie. Sie enthält neben der klassischen Funktionalität anderer Programmiersprachen 
vor allem Sprachkonstrukte, die ein modernes Software-Engineering unterstützen. 
Ein Aspekt ist die Unterstützung umfangreicher Programmierprojekte. Ein weiterer 
Aspekt ist die Unterstützung spezieller Anforderungen aus dem Bereich der Prozeß- 
steuerungen. Charakteristische Eigenschaften von Ada sind: 


® Datenabstraktion 


® Modularisierung mit separater Übersetzung und Konsistenzprüfung der Schnitt- 
stellen durch den Compiler 


® Erzeugung parametrierbarer Softwarekomponenten mit Hilfe von Generics 
® Exception Handling 


® Tasking mit einem Intertask-Kommunikationskonzept, das das Hoare-Modell 
der Communicating Sequential Processes nachbildet 


Der Sprachumfang von Ada ist durch die identischen Standards ANSV/MIL-STD 
1815A, ISO 8652 und DIN 66268 verbindlich festgelegt. 


BASIC 
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SINIX-Ada ist eine Portierung des von der Firma Meridian Software Systems lizen- 
sierten Compilersystems. Darin sind die Teile Compiler, Optimierer, Binder, Biblio- 
thekssystem und Ada-Debugger enthalten. Neben den Standardpaketen gemäß der 
Ada-Norm enthält die Bibliothek weitere vordefinierte Pakete, die der Verein- 
fachung der Ein-/Ausgabe dienen und andere nützliche Funktionen zur Verfügung 
stellen. Die SINIX-Systemschnittstelle wird mit dem Package Musix unterstützt. 


SINIX-BASIC ist mit seinem Interpreter ein komfortables Programmiersystem, ins- 
besondere für den weniger routinierten Programmierer. Der Interpreter analysiert 
während des Editierens die Programmzeile auf Syntaxfehler und während des Pro- 
grammablaufs auf Laufzeitfehler, bevor sie ausgeführt wird. Das erleichtert die Er- 
stellung und die Korrektur von Programmen. Zusätzliche Hilfen bieten der Pretty 
Printer, der zum Aufzeigen logischer Strukturen dient, und die HELP-Funktion. 


BASIC ist heute eine leistungsfähige Programmiersprache. Insgesamt stehen dem 
Programmierer 170 verschiedene Anweisungen, Funktionen und Kommandos zur 
Verfügung. Es existieren außerdem mathernatische Basisfunktionen und String- 
handling-Funktionen, und der Programmierer kann zwischen Dezimal- und Gleit- 
punktarithmetik auswählen. Für die Verarbeitung der Daten stehen sequentielle, in- 
dizierte und direkte Zugriffsmethoden zur Verfügung. 


Um für die fertig ausgetesteten Programme den Interpretations-Overhead zu ver- 
meiden, können BASIC-Programme auch kompiliert werden. Für beide Ausfüh- 
rungsarten des Programms, Interpreter- und Compiler-Programm, gibt es einen 
Sprachanschluß für C-Objektmodule. 


Der C-Compiler des Entwicklungspakets unterstützt sowohl den durch ANSYISO 
standardisierten als auch den von Kernighan & Ritchie [B.W. Kernighan & D.M. 
Ritchie: Programmieren in C, 1983] definierten Sprachumfang. Der Sprachumfang 
von K&R ist konform zu den X/Open Portability Guides XPG2 und XPG3. Der 
Sprachumfang von ANSVISO entspricht dem Sprachumfang von C im XPG4. 


Auf den SINIX-Systemen werden Spracherweiterungen durch den Compiler unter- 
stützt, die vom UNIX-PCC-Compiler definiert wurden (z.B. #pragma weak). 
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Das Frontend erzeugt den ULS-Zwischencode für den Optimierer bzw. den nachge- 
schalteten Codegenerator. Es wird auf allen SINIX-Systemen und dem BS2000 ein- 
gesetzt. Damit ist die Portabilität der C-Quellen sichergestellt. Die vom Compiler 
generierten Objekte entsprechen den Anforderungen der SINIX-Systeme hinsicht- 
lich des erzeugten Objektformats ELF und den übrigen Konventionen, die für jede 
unterstützte Architektur in einem Application Binary Interface dokumentiert sind 
(z.B. Registersicherung, Calling-Konventionen). Somit können die Objekte ohne 
Probleme mit denen des UNIX-C-Compilers von USL zu einem ablauffähigen Pro- 
gramm gebunden werden. 


Der C-Compiler erzeugt generell gemeinsam benutzbaren Code; gemeinsam be- 
nutzte Bibliotheken können ebenfalls mit ihm erstellt werden. Zum Testen der er- 
zeugten Objekte mit dem Debugger DBX wird optional die Symbolinformation im 
sogenannten DWARF-Format erzeugt, das als De-facto-Standard der ULS gilt. 


Der SINIX-C++ V2.1 Compiler unterstützt den Sprachumfang, der in dem Buch 
von Ellis/Stroustrup [The Annotated C++ Reference Manual, 1990] beschrieben ist. 
Der Sprachumfang umfaßt insbesondere Einfach- und Mehrfachvererbung, abstrak- 
te Klassen und Polymorphismus. Die Stream V/O entspricht der Definition von 
AT&T/USL. Mit der Version C++ V3.0 wird das Sprachmittel „Templates” unter- 
stützt. Für die Version C++ V4.0 wird voraussichtlich das „Exception Handling“ an- 
geboten. Eine Standardisierung von C++ durch ANSI und ISO/IEC ist ab 1995 zu 
erwarten. Eine Klassenbibliothek mit fundamentalen Containerklassen kann zusätz- 
lich bezogen werden. 


Der Compiler, ein Sprach-zu-Sprach-Übersetzer, erzeugt aus dem C++-Quellpro- 
gramm ein C-Quellprogramm, das dann vom C-Compiler übersetzt wird. Der 
Sprach-zu-Sprach-Übersetzer und die Bibliotheken wurden von USL lizensiert und 
auf SINIX portiert. 


Mit dem Debugger DBX können die C++-Programme symbolisch getestet werden. 
Insbesondere werden auch objektorientierte Eigenschaften, wie z.B. Mehrfachver- 
erbung, Memberfunktionen und Operatorfunktionen vom Debugger DBX unter- 
stützt. 


COBOL 
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Die Objekterzeugung erfolgt vollständig durch den C-Compiler. Damit genügen die 
generierten Objekte den Anforderungen der SINIX-Systeme hinsichtlich des er- 
zeugten Objektformats ELF und den übrigen Konventionen, die für jede unterstütz- 
te Architektur in einem entsprechenden Application Binary Interface dokumentiert 
sind. 


Der SINIX-COBOL-Compiler COB85 ist ein von Micro Focus lizensiertes Pro- 
dukt. Er unterstützt neben dem aktuellen Standard ANS8S auch noch den älteren 
Standard ANS74, sowie die X/Open Portability Guides XPG2, XPG3 und in Kürze 
auch XPG4. Außerdem sind IBM-, Ryan McFarland-, Data General- und Microsoft- 
kompatible Sprachumfänge einstellbar. Damit bietet COB85 einen modernen 
Sprachumfang mit strukturierter Programmierung, reichhaltiger Verarbeitung nu- 
merischer Daten und Zeichenreihen, leistungsfähiger Ein-/Ausgabe-Funktionalität 
mit Mehrbenutzer-Fähigkeit, integrierter Bildschirmverarbeitung, Report Writer 
und Sort. COB85 ist in die Systemumgebung der SINIX-Systeme integriert und un- 
terstützt gemeinsam benutzte Bibliotheken für das Laufzeitsystem und die COBOL- 
Objekte. 


Der COBOL-Compiler COB85 besteht aus drei Teilen: 


® Der Checker überprüft das COBOL-Programm syntaktisch und semantisch und 
erzeugt einen Zwischencode (int-code), der interpretierbar ist. Dieser Zwischen- 
code kann mit dem Debugger ANIM85 getestet werden. 


® Der Native Code Generator erzeugt aus dem Zwischencode einen ausführbaren 
Maschinencode, der gebunden und ausgeführt werden kann. 


® Das Laufzeitsystem wird zu dem ausführbaren Maschinencode dazugebunden, 
um den korrekten Ablauf des Programms zu gewährleisten. Daneben enthält das 
Laufzeitsystem den Interpreter für den Zwischencode. 


Damit hat der Programmierer die Möglichkeit, seinen Entwicklungszyklus zu opti- 
mieren, ohne Nachteile für einen optimalen Ablauf seiner Programme in Kauf neh- 
men zu müssen. 


71 


5 Entwicklungsumgebung 


72 


Das COBOL-Compilersystem bietet eine umfangreiche Werkzeugumgebung: 


® ANIMS8S5 ist ein Debugger, der ein bildschirmorientiertes Testen von COB85- 
Programmen auf Sourceebene gestattet. Er erlaubt die Unterbrechung von Pro- 
grammen an beliebigen Anweisungen, die Ablaufverfolgung und das Verändern 
von Variablen. 


® FORMS2 ist ein Hilfsmittel zur Entwicklung von Masken auf der Basis des 
XPG2 Screen Handlings. 


® Advanced Environment ist ein Zusatzprodukt, das Werkzeuge anbietet, die die 
Entwicklung von COBOL-Programmen produktiver gestalten: 


- Advanced Animator erlaubt, zusätzlich zu den normalen Animator-Funktio- 
nen, die Ausgabe von Programmstrukturen, den Test der Programmstruktu- 
ren und die Überwachung der Variablen in Fenstern. Außerdem ist ein Ana- 
lyzer zur Analyse der COBOL-Programme enthalten. 


- Screens bietet die komfortable, interaktive Erzeugung von Masken auf Basis 
des XPG3 Screen Handlings. 


- Session Recorder unterstützt die automatische Aufzeichnung des Pro- 
grammablaufs und dessen Wiederholung. 


Die nächste Version von COB85 wird auf Micro Focus COBOL V3 basieren. Sie 
wird die Definition des X/Open XPG4 voll unterstützen. Außerdem werden Intrin- 
sic Functions, ein offizielles Addendum zum ANS8S5-Standard, angeboten. Dieses 
Addendum enthält Funktionen für die technisch-wissenschaftliche und kommerzi- 
elle Datenverarbeitung. 


Die Werkzeugumgebung ist durch eine komfortable Menüoberfläche handlich ge- 
macht worden. Daneben wird als zusätzliches Produkt das Dialog System zur Mas- 
kenentwicklung angeboten. Dieses Werkzeug erlaubt es dem Programmierer, die 
Maskendefinition vollkommen aus einem Programm auszulagern und dadurch mit 
einem Programm verschiedene Bildschirmmasken zu bedienen, ohne neu überset- 
zen zu müssen. 
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FORTRAN 


FORTRAN ist die wichtigste Programmiersprache für technische und wissenschaft- 
liche Anwendungen. Die heute noch im wesentlichen verwendete Sprache basiert 
auf dem FORTRAN 77-Standard gemäß der Norm ANSI X3.9-1978. 


Der FORTRAN77-Compiler für SINIX ist eine Eigenentwicklung von Siemens 
Nixdorf. Er enthält einige Erweiterungen zum Sprachstandard, wie z.B. zusätzliche 
Datentypen und die Verwendung des C-Präprozessors. Der Compiler ist auf allen 
SINIX-Systemen validiert und mit der optimierten mathematischen Bibliothek 
XPG3- und XPG4-konform. 


Der Compiler erzeugt mehrfach benutzbare Objekte. Mehrfach benutzbare Funktio- 
nen können dynamisch nachgeladen werden. Für den Programmtest steht die sym- 
bolische Testhilfe DBX zur Verfügung. 


Ein Compiler für den FORTRAN9O-Standard ist in der Entwicklung. Er bietet lei- 
stungsfähige Komponenten zur Bearbeitung von Feldern, benutzerdefinierte Daten- 
typen, Pointer und ein leistungsfähiges Modulkonzept. Der FORTRAN90O-Comypi- 
ler von Siemens Nixdorf wird die meisten Spracherweiterungen des BS2000- 
FORTRAN-Compilers FORI unterstützen (z.B. die variable Länge von Zeichen- 
ketten), um eine einfache Migration zwischen den eigenen Mainframe- und 
Midrangesystemen zu gewährleisten. 


Pascal-XT 


Die von N. Wirth entwickelte Programmiersprache Pascal zeichnet sich durch ein 
besonders klares und kompaktes Sprachdesign aus. Pascal ist vor allem im univer- 
sitären Bereich verbreitet. Es gibt zahlreiche Compiler, die auf der ISO-Norm 7185 
basieren und in der Regel auch Spracherweiterungen unterstützen. Seit 1991 gibt es 
einen neuen Standard: Extended Pascal ISO 10206. Diese Programmiersprache hat 
aber noch keine Verbreitung gefunden. 


Der Pascal-XT SINIX-Compiler unterstützt ebenfalls eine eigendefinierte Erweite- 
rung des Standards ISO 7185, die zwar syntaktisch abweicht, aber funktional dem 
Extended Pascal stark verwandt ist. Es gibt einen Programmkonverter, der 
Pascal-XT in Extended Pascal umwandelt. 
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Die symbolische Testhilfe PATH ist Teil des Pascal-XT-Compilers. Das gesamte 
Pascal-XT-System ist eine Eigenentwicklung von Siemens Nixdorf, die auf SINIX 
und BS2000 verfügbar ist. 


Mit der Programmiersprache PROLOG kann eine besonders hohe Produktivität bei 
der Entwicklung von Anwendungen erreicht werden, die Suchstrategien, Regel- 
mengen, Ableitungs- und Induktionstechniken, symbolisches Rechnen oder Mu- 
sterverarbeitung zum Inhalt haben. Siemens Nixdorf setzt PROLOG erfolgreich in 
technologischen Kernbereichen der Produktion und als Implementierungssprache 
für wissensbasierte Produkte ein. 


Mit SNI-PROLOG V3.0 bietet Siemens Nixdorf als erster Hersteller eine zum ISO- 
Normenentwurf kompatible Implementierung der Programmiersprache PROLOG 
an. 


Darüber hinaus bietet SNI-PROLOG ein ausgereiftes Modul-Konzept, program- 
mierte Behandlung von Ereignissen, Ausnahmen und Signalen, sowie einen opti- 
mierenden inkrementellen Compiler und Decompiler. Das Modul-System von 
SNI-PROLOG wurde als Basis des ISO-Normenentwurfs Teil 2 ausgewählt. 


SNI-PROLOG verfügt über eine OSF/Motif-basierte grafische Entwicklungsumge- 
bung mit einem integrierten Editor, einer ausgereiften Testhilfe und einem Hyper- 
text-basierten Hilfesystem. Außerdem gibt es eine Reihe von konfigurierbaren 
Schnittstellen zu anderen Systemen, wie z.B. eine Datenbankschnittstelle zu 
INFORMIX. SNI-PROLOG ist nicht nur auf allen SINIX-Plattformen, sondern 
auch auf BS2000, MS-DOS und anderen UNIX-Plattformen (SGI, SUN, HP, 
R6000) verfügbar. 


Die ausgezeichnete Leistungsfähigkeit der mit SNI-PROLOG erstellten Anwen- 
dungen wird durch Optimierungsstrategien wie Klauselindizierung und flaches 
Backtracking im hochoptimierten inkrementellen Compiler erreicht. Die volle au- 
tomatische Garbage Collection über alle dynamische Speicherbereiche, sowie die 
implizite Anpassung des zugewiesenen Speichers an die Bedürfnisse einer Anwen- 
dung, führen zu einem ökonomischen Umgang mit Ressourcen bei Ein- und Mehr- 
platzsystemen. 
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Zur Optimierung von Problemlösungen haben sich Constraints (Wertebedingun- 
gen) als geeignetes Mittel in PROLOG erwiesen. Die Constraint-Technologie von 
SNI-PROLOG (ab der Version 3.1) bietet mit verschiedenen Klassen von Wertebe- 
dingungen neue, wirkungsvolle Mittel zur Lösung von Aufgaben aus Industrie und 
Operations Research an, die mit traditionellen PROLOG-Systemen oder konventio- 
neller Software nur schwer oder überhaupt nicht zu behandeln sind. Beispiele dafür 
sind die dynamische Aufteilung von Ressourcen oder flexibles Scheduling als An- 
wendung von numerischen Constraints, sowie die Verifikation komplexer Systeme 
mit Boolschen Constraints. 


SINIX API 


Die Bedeutung von Schnittstellen für die Anwendungsprogrammierung hat mit der 
Verpflichtung zu offenen Systemen in den vergangenen Jahren zugenommen. Ein 
API (Application Programming Interface) ist eine offiziell unterstützte und veröf- 
fentlichte Definition einer Programmierplattform. Aber erst mit der Gewährleistung 
von APIs hat der Kunde zusätzlich die Sicherheit, daß Anwendungen, die unter Ver- 
wendung dieser Schnittstellen erstellt wurden, mit der nächsten Ausgabe der Soft- 
ware weiterhin ablauffähig sind. Das SINIX API wird in diesem Sinne von Siemens 
Nixdorf garantiert, andererseits aber auch regelmäßig um neue Standards erweitert. 


Das SINIX API definiert ein offenes System auf der Basis des Betriebssystems 
System V Release 4 von USL. Es erfüllt die Schnittstellenstandards POSIX, XPG3 
und XPG4. Der Kunde ist damit in der Lage, seine Systementscheidungen flexibel 
zu treffen, ohne Rücksicht auf den Umfang seiner Investitionen in bestehenden An- 
wendungen, die für SINIX entwickelt wurden, ganz im Gegensatz zu APIs proprie- 
tärer Betriebssysteme, die die Auswahl des Kunden beschränken. Um dem Kunden 
immer die aktuellsten Systemlösungen zur Verfügung zu stellen, verfolgt Siemens 
Nixdorf diese Standards und folgt auch dem Entwicklungspfad der USL bezüglich 
der Zukunft des System V Release 4 (SVR4) API. 


Im Zentrum des SINIX API steht ein API, das XPG3-konform und künftig auch 
XPG4-konform ist. Dies ist durch die Erlangung und laufende Erneuerung des 
XPG3 PLUS-Brandings für SINIX dokumentiert. In anderen Bereichen, wie bei 
den grafischen Bedienoberflächen (GUT) und den Netzwerkschnittstellen, bestand 
die Notwendigkeit über den Kern des XPG3-API hinauszugehen. Der Ansatz von 
Siemens Nixdorf geht davon aus, soweit möglich Industriestandards in das SINIX 
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API zu integrieren und dort wo es notwendig war, zusätzlich Siemens Nixdorf-spe- 
zifische Funktionalität hinzuzufügen. Sobald neue Standards entwickelt werden, 
fügt Siemens Nixdorf diese in das SINIX API ein und ersetzt gegebenenfalls die 
Siemens-Nixdorf-spezifischen Schnittstellen durch die Standards. Dies gilt insbe- 
sondere für alle Komponenten des XPG4. 


Das SINIX API besteht aus den Elementen, die in Abbildung 5-2 aufgeführt sind. 


Motif Streams 


Programmier- Werkzeuge 
sprachen 


TCP/IP SQL 


XPG3/XPG4 
OSI Standards DCE 


Abbildung 5-2: Im SINIX API sind viele Standards enthalten. Im Mittelpunkt aber stehen die XPG3 PLUS-Zertifi- 
zierung und umfassende XPG4-Zertifizierung. 
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Internationalisierung und Lokalisierung 


Locale 


Die SINIX-Implementierung des NLS (Native Language System) von X/Open er- 
möglicht die Entwicklung von Anwendungsprogrammen, die mit dem Anwender in 
den verschiedenen natürlichen Sprachen kommunizieren und die über Informatio- 
nen länderspezifischer Konventionen verfügen. Solche Programme machen keine 
Annahmen über die Sprache des Anwenders und den verwendeten Zeichensatz. Die 
sprach- und kulturspezifischen Daten und Texte werden getrennt von der Progam- 
mierlogik gehalten. Man bezeichnet diese Programme als internationalisierte Pro- 
gramme. 


NLS ermöglicht außerdem, internationalisierte Anwendungsprogramme zur Lauf- 
zeit mit der richtigen Landessprache und den länderspezifischen Konventionen zu 
versorgen. Dieser Prozeß wird als Lokalisierung bezeichnet. 


Die länder- und sprachspezifischen Informationen werden als Elemente einer sog. 
Locale zusammengefaßt. Dabei beschreibt die Locale in diesem Fall die vom An- 
wender einstellbare Arbeitsumgebung, ähnlich der von der Shell bekannten 
Arbeitsumgebung. Zu einer Locale werden die Beschreibungen der in einem Land 
oder in einer Region gebräuchlichen Konventionen oder auch die für einen Anwen- 
der individuell bevorzugte Arbeitsumgebung zusammengefaßt. Eine Locale darf 
aber nicht mit einer Sprache verwechselt werden. Sie beschreibt eine wesentlich 
umfassendere Umgebung. 


Entspricht der Name einer Locale den Konventionen aus dem X/Open Portability 
Guide (Issue 3 oder 4), wird er mit einer Kombination aus den drei Elementen Spra- 
che, Territorium und Zeichensatz benannt. Eine große Anzahl von Localen wird von 
SINIX-Systemen unterstützt: deutsche, amerikanische, englische, dänische, franzö- 
sische, russische, usw. 
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Kategorien 


Eine Locale läßt sich in noch feinere Gruppen unterteilen, die als Kategorien be- 
zeichnet werden. Sie erlauben einen flexibleren Zugriff auf bestimmte kulturelle In- 
formationen. Folgende Kategorien stehen zur Verfügung: 


Kategorie Einfluß auf: 


| Gesamte internationale Umgebung 


Zeichenklassen und Umwandlung von Klein- in Großbuchstaben und 
umgekehrt 


LC_COLLATE Sortierreihenfolge 


ee 
| Datums- und Zeitangaben 
LC_MONETARY ı Währungszeichen und Währungsformat 


! 
LC_NUMERIC | Dezimalpunktdarstellung, Exponentzeichen und Tausendertrennzei- 


chen 


LC_MESSAGES Meldungstexte und Antworten auf ja/nein-Fragen 


Basismechanismen 


Grundsätzlich können zwei Arten von Informationen in einer Locale enthalten sein: 


® programmspezifische Informationen: Das sind die Texte, die das Programm aus- 


gibt. Sie werden in sog. Message-Files oder Meldungskatalogen zusammenge- 
faßt. 


® programmunabhängige Informationen: Das wäre z.B. das aktuelle Datum oder 
die Landeswährung. Diese Information ist vernünftigerweise nur einmal pro 
Sprache als Locale vorhanden. Die programmunabhängigen Informationen wer- 
den in den sog. NLS-Datenbasen gehalten. Diese Datenbasen dürfen nicht mit 
kommerziellen Datenbanken wie INFORMIX verwechselt werden, sie stellen 
nur eine Sammlung von bestimmten länderspezifischen Daten dar. 


Ein internationalisiertes Programm greift erst zur Ablaufzeit auf den Meldungska- 
talog bzw. die NLS-Datenbasis zu. 
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Die Einstellung einer den individuellen Erfordernissen entsprechenden nationali- 
sierten Arbeitsumgebung ist mit Hilfe von Umgebungsvariablen möglich. Interna- 
tionalisierte Programme entnehmen dem Wert der Variablen die Information, wel- 
che Locale zu verwenden ist. Auf Informationen bestimmter Kategorien wird 
gezielt mit Hilfe der entsprechenden Umgebungsvariablen zugegriffen: 
LC_COLLATE, LC_CTYPE, usw. 


Zusätzlich sind folgende Variablen verfügbar: 


Die Variable LANG dient als Standardwert für alle Kategorien, die nicht explizit ge- 
setzt sind. 


Die Variable LC_ALL setzt die gesamte Umgebung auf die entsprechende Sprache. 


Editoren 


Editoren sind die Schreibwerkzeuge des Software-Entwicklers, mit denen er 
Sourcecode erstellt und seine Arbeit dokumentiert. Ohne Editor wäre die moderne 
Programmentwicklung unmöglich und gerade in diesem Bereich ist die Auswahl 
des richtigen Werkzeugs entscheidend für Produktivität und Qualität. Die Produkti- 
vität des Programmierers kann durch Editoren mit leistungsfähigen Editier- und 
Suchfunktionen, mit kontextsensitiven Repräsentationshilfen und durch eine effi- 
ziente Zusammenarbeit mit Compilern bei der syntaktischen und semantischen 
Überprüfung von Programmen wesentlich verbessert werden. Ein Editor mit einer 
klaren, gut strukturierten Kommandoschnittstelle, der mit wenigen Tastenkombina- 
tionen bedient werden kann, ist sehr hilfreich. Außerdem spielen grafische und ob- 
jektorientierte Schnittstellen für Editoren eine zunehmend größere Rolle. 


Im SINIX-System gibt es mehrere Editoren. Sie sind für verschiedene Zwecke und 
Editierumgebungen vorgesehen. Die zeilenorientierten Editoren ed, ex und edit eig- 
nen sich für kleinere, schnell auszuführende Operationen. Der stapelorientierte Edi- 
tor sed wird innerhalb von Shellskripts zur Datenbearbeitung verwendet. Die bild- 
schirmorientierten Editoren vi und ced (SINIX-spezifisch) entsprechen eher dem 
Bild eines modernen Editors. Während der vi durch seine Vielfalt und Allgegenwär- 
tigkeit in der UNIX-Welt überzeugt, macht die einfache Bedienung den ced eben- 
falls sehr attraktiv. 
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Der MAXed ist ein SINIX-spezifischer Editor, der eine universell einsetzbare Edi- 
tierumgebung zur Verfügung stellt, die auf alle Aspekte der Softwareentwicklung 
abgestimmt ist. Der MAXed bietet bei nur kurzer Einarbeitungszeit und einfacher 
Bedienung über leicht zu merkende Kommandos sowohl dem Neuling als auch dem 
Profi einen enormen Funktionsumfang. Er ermöglicht die Erstellung von Source- 
code und der dazugehörigen Dokumentation, ohne daß zusätzlich auf ein Textver- 
arbeitungssystem zurückgegriffen werden muß. 

Zu den herausragenden Eigenschaften des MAXed zählen: 

® die einfache Bedienung mit konfigurierbaren Funktionstasten 
® die kurze Einarbeitungsphase 

® die vollständigen und flexiblen Editierfunktionen 

® ein bequemer und effizienter Editier-Compiler-Zyklus 

® die Unterstützung der Textformatierung 


® die garantierte Qualität und Kompatibilität 


UNIX -Dienstprogramme 
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In allen UNIX-Systemen, so auch in SINIX, gibt es zahlreiche Dienstprogramme, 
die für die Programmentwicklung außerordentlich hilfreich sind. Dies ist ein ange- 
nehmer Nebeneffekt der Fortschritte und Verbesserungen, die über die Jahre hinweg 
durch die Verwendung von UNIX in Universitäten und Forschungseinrichtungen 
eingeflossen sind. Die drei Beispiele make, lex und yacc sollen stellvertretend einen 
Eindruck von diesen Werkzeugen vermitteln. 


Das Dienstprogramm make ist ein ausgesprochen wertvolles Werkzeug bei der Er- 
stellung und Pflege von Programmen und Programmsystemen. Für Programmierer, 
die damit Erfahrungen gesammelt haben, ist es überhaupt nicht mehr wegzudenken. 
Das verwendete Prinzip ist denkbar einfach. Der Programmierer verwendet eine 
Datei, das sog. „Makefile”, um zu beschreiben, wie ein bestimmtes Programm- 
system zu erzeugen ist. Diese Datei enthält Informationen wie die Liste alle Source- 
code-Dateien, mit welchem Kommando die einzelnen Sourcecode-Dateien über- 
setzt werden sollen, usw. Der Programmierer braucht dann nur noch das 
Dienstprogramm make mit dem Makefile als Argument aufzurufen. make liest die 
Informationen in der Datei Makefile, erzeugt die entsprechende Umgebung und 
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führt die entsprechenden Kommandos zur Übersetzung der Sourcecode-Dateien 
aus. Wenn die kompilierte Version einer bestimmten Datei bereits die letzten Ände- 
rungen enthält, wird die Datei nicht neu übersetzt. Ein Dienstprogramm wie make 
ist selbst bei der Entwicklung einfacher Programme sehr hilfreich. Wenn aber meh- 
rere Programmierer zusammen an einem großen Projekt arbeiten, ist es unverzicht- 
bar. Es stellt sicher, daß keine Programmdatei vergessen wird und alte Dateiversio- 
nen nicht versehentlich wiederverwendet werden. 


Das Dienstprogramm lex führt eine lexikalische Analyse von Textdateien durch. 
Der Entwickler erzeugt eine Eingabedatei für /ex, die Zeichenketten und reguläre 
Ausdrücke enthält, nach denen gesucht werden soll, und schließlich den C-Code, 
der ausgeführt werden soll, wenn die Zeichenkette oder der reguläre Ausdruck ge- 
funden wurde. Aus der Eingabedatei wird ein C-Programm erzeugt. Dieses Pro- 
gramm kann dann übersetzt und dazu verwendet werden, Textdateien zu durchsu- 
chen und die entsprechende Ausgabe zu erzeugen. Zur Veranschaulichung kann 
man sich einen Programmierer vorstellen, der in Hunderten von C-Programmen an 
den verschiedensten Stellen den Namen seiner Firma einprogrammiert hat (Copy- 
right-Vermerke, Bildschirmausgaben, usw.). Nun muß die Firma aufgrund eines Zu- 
sammenschlusses ihren Namen ändern. Mit dem Dienstprogramm lex kann der Pro- 
grammierer sehr schnell ein /ex-Programm schreiben, das den Namen der alten 
Firma durch den neuen ersetzt. Was zunächst als enorme Anstrengung erschien, ist 
zu einer einfachen Aufgabe geworden. 


Die hintergründig-humorvolle Abkürzung yacc steht für „yet another compiler 
compiler”. Dieser Compiler wird dazu verwendet, Programme zu erzeugen, die Ein- 
gabedateien analysieren können, welche in einer speziellen, möglicherweise vom 
Entwickler erfundenen „Programmiersprache” geschrieben sind. Der Entwickler 
erzeugt eine Eingabedatei mit den Regeln dieser „Programmiersprache‘“ und be- 
nutzt lex dann zur Generierung des Programms, das die Analyse durchführt. Eine 
mögliche Anwendung für yacc wäre die Definition einer kleinen Programmierspra- 
che, die es Entwicklern erlaubt, Programme für ganz spezifische Aufgabentypen zu 
erzeugen. Anschließend könnten sie das mit yacc generierte Programm dazu ver- 
wenden, um daraus einen C-Code zu erzeugen. 
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Debugger 
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Ein Debugger ist ein Werkzeug zur Analyse des dynamischen Verhaltens einer An- 
wendung. Unter der Kontrolle eines Debuggers kann der konkrete Ablauf einer An- 
wendung verfolgt werden. Außerdem ist es möglich, in den Programmablauf einzu- 
greifen, indem z.B. Variablen neue Werte zugewiesen werden. Debugger werden 
häufig eingesetzt, um Laufzeitfehler zu finden, die statisch, etwa durch einen Com- 
piler, nicht erkannt werden können. Die Bezeichnung Debugger ist etwas irrefüh- 
rend, denn der Debugger behebt selbst keine Fehler, sondern hilft dem Entwickler, 
sie zu lokalisieren. Neben der Fehlersuche wird der Debugger auch bei der Einar- 
beitung eines Entwicklers in fremden Code und bei der kritischen Beobachtung von 
funktionierenden Datenstrukturen oder Algorithmen hinsichtlich ihrer Performanz 
oder ihres Ressourcenverbrauchs verwendet. 


In Entwicklungsumgebungen mit grafischen Workstations werden Fenstertechni- 
ken, grafische Repräsentation und Interaktionsmechnismen für eine simultane Wie- 
dergabe des Prozeßstatus, des Quellprogrammkontextes und der Bildschirmausga- 
ben des Prozesses mit dem Debugger verwendet. 


Die Siemens Nixdorf Sprachen-Systeme COBOL, Pascal, PROLOG und Ada ver- 
fügen über jeweils eigene Debugger. C, C++ und FORTRAN77 haben einen ge- 
meinsamen Debugger: DBX. Der Debugger DBX wurde ursprünglich an der Uni- 
versity of California in Berkeley entwickelt. DBX hat in der UNIX-Welt eine weite 
Verbreitung gefunden, was dazu geführt hat, daß viele Entwickler mit seiner Basis- 
funktionalität vertraut sind. 


Die Siemens-Nixdorf-Version des DBX ist auf allen Systemen mit SINIX-Compi- 
lern verfügbar. API-konforme Anwendungen werden vom DBX voll unterstützt. 
DBX kann auch auf der Maschinenebene arbeiten. Außerdem unterstützt DBX die 
übliche Debugger-Funktionalität wie Step, Trace und das Setzen von bedingten und 
unbedingten Haltepunkten. Variablen können automatisch überwacht werden. Die 
symbolische Adressierung von Variablen und Funktionen ist möglich. Einzelne 
Funktionen aus der Anwendung können direkt vom DBX aufgerufen werden. Diese 
Funktionalität ist bei modularem Testen sehr hilfreich. Der DBX-Benutzer kann be- 
liebige Ausdrücke, bestehend aus Programm-, Variablen- und Funktionsaufrufen 
von DBX, evaluieren lassen. Darüberhinaus besitzt der Debugger DBX eine Viel- 
zahl weiterer Leistungen, die in bestimmten Situationen nützlich sind. 
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Die Basisfunktionalität ist bei allen drei unterstützten Programmiersprachen gleich. 
Darüber hinaus unterstützt der DBX die Besonderheiten der einzelnen Program- 
miersprachen. In C++ werden u.a. überladene Funktionen und Operatoren unter- 
stützt. Der Anwender arbeitet direkt mit den symbolischen Namen aus der Anwen- 
dung und nicht mit den künstlichen Namen, die vom Compiler erzeugt werden. Bei 
FORTRAN-Programmen werden u.a. COMMON, EQUIVALENCE und Entry- 
Points unterstützt. 


Der Debugger DBX ist auch in der Lage, Anwendungen zu verarbeiten, die aus Mo- 
dulen unterschiedlicher Source-Programmiersprachen bestehen. 


Die neuste Version von DBX wurde um eine OSF/Motif-basierte grafische Bedien- 
oberfläche erweitert. Dadurch wird nicht nur die Bedienung erleichtert, sondern die 
Darstellung der Anwendung und ihrer Daten wird wesentlich übersichtlicher, wo- 
durch Geschwindigkeit und Zuverlässigkeit der Entwicklungsarbeit zunehmen. 
Diese Version läßt sich auch in die weiter unten auf Seite 92 beschriebene OSCE- 
Entwicklungsumgebung einbetten. Die Fähigkeit, Mehr-Prozeß-Anwendungen und 
gemeinsam benutzte Bibliotheken (shared libraries) zu analysieren, versetzt den 
Debugger DBX in die Lage, den Anforderungen von Entwicklern komplexer An- 
wendungen gerecht zu werden. 


Konfigurations-Management 


In vielen Projekten wird heutzutage das Software-Konfigurations-Management 
noch immer nicht konsequent eingesetzt. Dabei ist es eine Disziplin, die ähnlich der 
Qualitätssicherung wesentliche Beiträge zum Erfolg eines Projekts leisten kann. 
Während man bei der Hardware eine Änderung oftmals noch sehen kann, ist dies 
bei der Software häufig nicht der Fall. Deshalb können Projektstand und Fortschritte 
nur sehr schwer transparent gemacht werden. Es ist kompliziert, die Softwareände- 
rungen zu verfolgen und Nebeneffekte sowie Interaktionen zu überwachen. Selbst 
die kleinsten Manipulationen am Code können große Probleme verursachen. Ohne 
gesicherte Informationen über Änderungen ist es oft schwer, die Änderungen zu 
entdecken, die zu einem Problem geführt haben. Der Änderungsprozeß in der Soft- 
wareentwicklung muß durch ein Konfigurations-Management kontrolliert und 
verfolgt werden, wenn ein Projekt effizient arbeiten und Erfolg haben soll. Um die- 
ses Ziel zu erreichen müssen folgende Aufgaben erfüllt werden: 
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eindeutige Identifikation aller Bestandteile einer Software (configuration identi- 
fication) 


Einbringen und Freigeben von Änderungen (configuration control) 
Verfolgen und Sichtbarmachen von Änderungen (configuration auditing) 


objektives Berichten über den Änderungsstand an das Management (configura- 
tion accounting). 


Sollen diese Aufgaben konsistent und zuverlässig durchgeführt werden, empfiehlt 
sich der Einsatz eines rechnergestützten Verfahrens. 


Unter UNIX stehen zwei Pakete von Programmen zur Verfügung, die die Verwal- 
tung von Software erlauben. Das Source Code Control System (sccs), das in SINIX 
enthalten und im X/Open Portability Guide (XPG) beschrieben ist, sowie das Revi- 
sion Control System (rcs), das als Public Domain Software erhältlich ist. Die beiden 
Systeme sind sich in ihrer Funktionalität sehr ähnlich. 


KMS-X 
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Zu ihren Merkmalen gehören: 
® Speicherung beliebig vieler Versionen einer Datei 
® automatische Identifizierung von Versionen 


. Verwendung der Deltamethode zur Speicherung der Versionen (die Speicherung 
von Änderungen einer Basisversion zu einer Änderungsversion, im Gegensatz 
zur Speicherung der ganzen Datei für jede Version) 


® Speicherung von Datum, Grund, versionsabhängigen und versionsunabhängi- 
gen Attributen 


® Versionsidentifikationen in Sourcedateien, Objektmodulen und gebundenen 
Programmen 


® Koordination von Zugriffen durch mehrere Benutzer 


Diese Systeme bieten eine gute Unterstützung für die Verfolgung von Änderungen 
und zur Aufzeichnung der Historie einzelner Softwarekomponenten. Die Beherr- 
schung von Strukturen und deren Abhängigkeiten in großen Softwaresystemen wird 
nur marginal unterstützt. Außerdem unterstützen weder sccs noch rcs das Verwalten 
von Objektcode oder anderer nicht-ASCII-Dateien. 


Um ein leistungsfähiges Konfigurations-Management aufzubauen, müssen die Me- 
chanismen der Versionskontrolle, wie sie von rcs und sccs angeboten werden, noch 
mit geeigneten Funktionen erweitert werden. Dieser Weg wurde auch in der Ent- 
wicklung des Konfigurations-Management-Systems für SINIX (KMS-X) einge- 
schlagen. 


Die wichtigsten Erweiterungen in KMS-X sind: 


® Alle Objekttypen und Dateien — also auch Objektmodule, Binärdateien und 
Phasen — können mit KMS-X verwaltet werden. 


® Automatisches Erstellen und Pflegen von Konfigurationslisten. Mit Hilfe von 
Konfigurationslisten wird der aktuelle Zustand eines Software-Systems festge- 
halten. Dadurch wird dieser Stand reproduzierbar gemacht und kann unabhän- 
gig von der Weiterentwicklung des aktuellen Systems für sich weiterentwickelt 
werden. 
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® Unterstützung strukturierter Hierarchien. Damit können ganze SINIX-Dateiver- 
zeichnissysteme kontrolliert und bearbeitet werden. 


Unterstützung von Varianten. Durch Varianten wird die Entwicklung und Pflege 
von Softwaresystemen vereinfacht, die aus gemeinsamen und variantenspezifi- 
schen Teilen bestehen. Ein Beispiel wäre die Softwareentwicklung für verschie- 
dene Zielsysteme. Bestimmte Softwarekomponenten sind ohne Änderung auf 
allen Zielsystemen verwendbar (common). Die restlichen Komponenten müs- 
sen aber an das jeweilige Zielsystem angepaßt werden. Sie werden dann in 
KMS-X komfortabel und variantenspezifisch verwaltet. 


Einbindung in vorhandene Umgebungen durch ein Anpassungskonzept. Um mit 
KMS-X benutzerbezogen arbeiten zu können, wird dem Anwender eine Profil- 
Ebene zur Verfügung gestellt. Der Anwender kann so sein Profil an seine 
Arbeitsweise anpassen. Auch der nutzbare Funktionsumfang kann benutzerbe- 
zogen konfiguriert werden. In diesem Fall kann der gesamte Funktionsumfang 
auf den Konfigurationsverwalter oder den Projektleiter beschränkt werden. 


Mit KMS-X steht ein flexibles Konfigurations-Management zur Verfügung. Es wer- 
den viele Verfahrenselemente angeboten, die an die speziellen Anforderungen und 
Konventionen eines Projekts angepaßt werden können. Aus diesem Grund kann 
KMS-X als projektübergreifende Produktbibliothek und auch als lokale Entwickler- 
bibliothek zum Einsatz kommen. Der Anwender ist in der Lage, KMS-X-Funktio- 
nen mit SINIX-Befehlen zu kombinieren. Somit lassen sich die vielfältigen Mana- 
gement-Aktionen für die Konfiguration zu leistungsfähigen Ablaufregeln 
zusammenfassen, die problemlos in die Softwareentwicklungsumgebung integrier- 
bar sind. KMS-X kann also als zentraler Bestandteil einer Softwareproduktionsum- 
gebung eingesetzt werden. 


Zur Zeit wird an der Entwicklung einer OSF/Motif-basierten Bedienoberfläche ge- 
arbeitet, die die bisherige Collage-Oberfläche ablösen wird. Weitere Schwerpunkte 
der Entwicklung sind die Anbindung von KMS-X an OSCE und die Integration mit 
einem Repository. 


5 Entwicklungsumgebung 


CASE-Werkzeuge 


Das GRAPES-Designwerkzeug 


Es ist bekannt, daß unvollständige bzw. falsche Vorgaben und Fehler in den frühen 
Designphasen als Hauptfehlerquelle bei der Erstellung von Softwareprodukten an- 
zusehen sind. Um diese Fehlerquellen weitgehend auszuschalten, muß einerseits 
eine optimale Kommunikation zwischen Anwendern und Entwicklern gewährlei- 
stet sein, und andererseits frühzeitig eine rigorose Überprüfung des Designs vorge- 
nommen werden. Dazu bedarf es einer leicht kommunizierbaren aber trotzdem for- 
malen Designmethode. GRAPES ist eine Designmethode, die diese 
Voraussetzungen erfüllt. Es werden für alle Designaspekte intuitive grafische Re- 
präsentationen angeboten. Gleichzeitig besitzt GRAPES eine formale Syntax und 
Semantik, auf deren Basis eine optimale Werkzeugunterstützung angeboten werden 
kann. Der Systemdesigner GRAPES-SD ist die zentrale GRAPES-Komponente mit 
der Designdokumente erstellt, geprüft und verwaltet werden. 


Editorenkomponenten 


Um Fehler bereits frühzeitig zu verhindern, besitzt GRAPES-SD Editorenkompo- 
nenten, die sich optimal auf jeden Dokumententyp einstellen. Ein Großteil der Feh- 
ler wird schon frühzeitig abgefangen, indem das Werkzeug bereits bei der Eingabe 
nur korrekte Konstrukte zuläßt. Für folgende Diagrammtypen werden u.a. Editoren- 
komponenten angeboten: 


Kommunikationsdiagramme (CD) 


Mit der CD-Editorenkomponente können Objekte in Unterobjekte strukturiert und 
die Kommunikation zwischen den Unterobjekten festgelegt werden. Der System- 
designer kann kompatible Kommunikationsschnittstellen für die Unterobjekte er- 
zeugen. 


Prozeßdiagramme (PD) 


Prozeßabläufe werden wohlstrukturiert entworfen. Vorgefertigte Ablaufkonstrukte 
können ausgewählt und in das Prozeßdiagramm eingefügt werden. Das grafische 
Layout wird automatisch neu berechnet. 
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Spezifikationsdiagramme (SD) 


Durch Anlegen von Prozeduren, Parametern, Variablen und Konstanten wird die 
Exportschnittstelle eines Moduls beschrieben. 


Entity-Relationship-Diagramme (ER) 


Es wird eine Datenmodellierung nach der ER-Methode unterstützt. Entities und Re- 
lationships können frei plaziert werden. Die Angaben zu Relationships, wie z.B. 
Kardinalitäten, werden syntaktisch überprüft. 


Alle Editorenkomponenten des GRAPES-SD sind mit einer komfortablen grafi- 
schen Bedienoberfläche ausgestattet (GUT), die die Vorteile der Mehrfenstertechnik 
voll zur Geltung bringt. Dadurch können Designdokumente in parallelen Fenstern 
betrachtet bzw. bearbeitet werden (z.B. ein Dokument, in dem eine Variable vor- 
kommt, parallel zum Dokument, das die Variable definiert). Die Copy/Paste-Funk- 
tion ermöglicht ein fensterübergreifendes Kopieren. Das Design erfolgt auf einer 
„unendlichen“ Zeichenfläche und kann stufenlos vergrößert oder verkleinert wer- 
den. Symbole und Linien sind direkt mit der Maus manipulierbar. Der Anwender 
wird durch zahlreiche Generierungsleistungen entlastet. Sollen zum Beispiel zwei 
Symbole durch eine Linie verbunden werden, reicht es aus, nur die betroffenen 
Symbole mit der Maus anzuklicken; das Werkzeug berechnet automatisch den Ver- 
lauf der Verbindung, ohne daß dabei Symbole geschnitten werden. Beim Verschie- 
ben von Symbolen werden alle Verbindungen vom und zum Symbol mit verscho- 
ben. Die Beschriftung von Verbindungen wird automatisch vom Werkzeug plaziert. 
Der Modellierer kann das Layout jederzeit automatisch berechnen lassen. Bei Än- 
derungen im Text werden die grafischen Symbole an die Textmenge angepaßt. Ge- 
langt man beim Bearbeiten des Designs an die Grenzen des sichtbaren Bereichs, 
wird der Bereich automatisch verschoben. Für die Texte stehen hilfreiche Such- und 
Ersetzungsfunktionen zur Verfügung. Außerdem gibt es eine mehrstufige Undo- 
Funktion. Häufig benötigte Funktionen werden als Buttons in einer „Toolbox” an- 
geboten. Die Help-Funktion unterstützt den unerfahrenen Anwender. 
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Der Modelleditor 


Trotz dezidierter Editorenkomponenten besitzt GRAPES-SD eine über alle Doku- 
menttypen integrierte Datenhaltung. Die Integration der Einzeldokumente zu einem 
Gesamtmodell erfolgt mit dem Modelleditor. Mit ihm werden Modelle aus Design- 
dokumenten hierarchisch aufgebaut. 


Eine wesentliche Komponente des Modelleditors ist der Editor für Hierarchie- 
diagramme (HD), mit dem die Dokumentenhierarchie erstellt und gepflegt wird. 
Das Hierarchiediagramm ermöglicht einen schnellen Zugriff auf die Designdo- 
kumente. Mit dem HD-Editor können Umbenennungen über das gesamte 
Design hinweg vorgenommen werden. 


Ein zweiter Aspekt des Modelleditors ist die Arbeitsstandsicherung. Startet ein 
Anwender GRAPES-SD erneut, so gelangt er genau in den Arbeitsstand, mit 
dem er den Editor zuletzt verlassen hatte. Die Arbeitsstandsicherung umfaßt 
auch einen benutzerbezogenen Arbeitsbereich für die in Arbeit befindlichen Do- 
kumente (Scratchdiagramme) und Referenzen in das Modell. Die Dokumente 
und Referenzen werden im Arbeitsbereich als Icons dargestellt, die mit Maus- 
klick geöffnet und dann bearbeitet werden können. 


Der dritte Aspekt ist die Mehrbenutzerfähigkeit des Modelleditors. Während der 
Bearbeitung werden Teilmodelle kurzfristig gesperrt. Wenn zu dieser Zeit ein 
konkurrierender Benutzer auf das Teilmodell zugreifen will, wird der Zugriff 
verweigert. Dadurch wird verhindert, daß die Änderungen eines Designers 
durch konkurrierende Bearbeitung verloren gehen. 


Jedem GRAPES-Designdokument können kundenspezifische Dokumente assozi- 
iert werden. Wenn solche Dokumente ausgewählt werden, werden die konfigurier- 
ten externen Werkzeuge angeboten. Bei Auswahl des externen Werkzeugs wird die 
Bearbeitung des kundenspezifischen Dokuments gestartet. Die Integration und Ver- 
waltung der geänderten Dokumente erfolgt innerhalb der GRAPES-Datenhaltung. 
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Modellanalyse 


Neben der dokumentspezifischen Prüfung zum Eingabezeitpunkt wird im 
GRAPES-SD eine systemweite Modellanalyse angeboten, die vom Anwender ex- 
plizit gestartet werden kann. Die Prüfkriterien der Modellanalyse sind Konsistenz, 
Vollständigkeit und Korrektheit. Viele Designfehler können durch diese statische 
Methode entdeckt werden. Beispiele dafür sind: 


® Werden Prozeduren, Variablen oder Konstanten eines Moduls korrekt verwen- 
det? 


® Findet zwischen zwei Prozessen ein korrekter Nachrichtenaustausch statt? 
® Werden Prozeduren, Parameter, lokale Variablen, usw. jemals benutzt? 


In einer Fehlerliste werden die erkannten Fehler und Warnungen festgehalten und 
können mit einem Fehlerbrowser abgearbeitet werden. Dabei werden die Fehler 
nacheinander präsentiert und zu jedem Fehler die betreffenden Diagramme bzw. 
Diagrammpaare ausgegeben. 


Auskunftsfunktion 


Während der Arbeit mit dem Systemdesigner steht jederzeit eine integrierte Aus- 
kunftsfunktion zur Verfügung. Sie informiert, wo die angegebenen Designelemente 
verwendet werden (Querverweise). Außerdem werden Designstrukturen in über- 
sichtlicher und konzentrierter Form angezeigt. Die Ergebnisse der Auskunftsfunk- 
tion können als Ausgangspunkt weiterer Untersuchungen dienen. 


Druckfunktion 
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Die Druckfunktion von GRAPES-SD führt eine automatische Paginierung der 
Designdokumente durch. Neben dem Posterdruck, bei dem das Dokument unverän- 
dert in Druckseiten aufgeteilt wird, steht ein Konnektorendruck zur Verfügung. Bei 
dieser Art der Druckaufbereitung werden Konnektorsymbole erzeugt, wenn Verbin- 
dungen über eine Druckseite hinausgehen und die Druckseite wird mit einem Rah- 
men versehen. Solche Konnektordrucke eignen sich besonders für das Abheften in 
technischen Dokumentationen. Vor dem Ausdrucken können die Ausgaben mit ei- 
ner Preview-Funktion kontrolliert werden. Als Ausgabeformate stehen Postscript 
und CGM zur Verfügung. 
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Verbindungen zu Textsystemen 


Für die Textsysteme HIT und FrameMaster werden Kopplungsbausteine angeboten. 
GRAPES-Dokumente können in Textdokumente dieser Systeme integriert werden 
(Mischdokument). Der Kopplungsbaustein garantiert, daß bei Änderungen der 
GRAPES-Dokumente die Mischdokumente aktualisiert werden. 


Datenmodellierung 


Mit GRAPES kann ein Datendesign mit den Mitteln der ER-Modellierung erstellt 
werden. Die Weiterverarbeitung des Datendesigns erfolgt mit dem Werkzeug 
RDDG. Dazu wird das ER-Modell geprüft und normalisiert. Sind Änderungen des 
ER-Modells nötig, werden die Änderungen interaktiv mit den Mitteln des GRA- 
PES-SD durchgeführt. Normalisierte ER-Modelle können in SQL-Datenbankbe- 
schreibungen umgesetzt werden. 


Modellinterpreter 


Es besteht die Möglichkeit, GRAPES-Modelle mit Hilfe eines Interpreters „auszu- 
führen“. Unter Verwendung geeigneter Modellierungstechniken (Z-Modellierung) 
liegen ausführbare Modelle bereits in ganz frühen Stadien des Designs vor. Die 
Kommunikation zwischen den Anwendungsexperten und den Entwicklern wird da- 
durch wesentlich effektiver. Zudem liefert die Modellinterpretation die erforderli- 
chen Informationen, um semantische Fehler im Design frühzeitig erkennen zu kön- 
nen. Bei der Modellinterpretation wird eine Unterscheidung zwischen Simulation 
und Ausführung eines Modells getroffen. 


Das Ziel der Simulation ist das Erkennen von Schwachstellen. Deshalb wird ein 
Modell ausgeführt und die Ergebnisse werden dann unter speziellen Gesichtspunk- 
ten, wie z.B. Häufigkeiten und Ablaufzeiten, betrachtet. 


Ziel der Modellausführung ist es, semantische Fehler des Designs zu erkennen und 
zu lokalisieren. Während einer Modellausführung werden der Ablauf sowie die Zu- 
stände und Datenbelegungen während des Ablaufs angezeigt. Die Modellausfüh- 
rung kann auch gezielt angehalten werden. 
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Generierung 


Ein mit GRAPES entworfenes Design kann in Code umgewandelt werden. Zur Zeit 
wird daran gearbeitet, eine Umsetzung anzubieten, die speziell auf OLTP-Anwen- 
dungen ausgerichtet ist. 


OSCE: Eine integrierte Software-Entwicklungsumgebung für SINIX 


Das ECMA-Referenzmodell für CASE, ein Modell für eine neue Generation von 
Software-Entwicklungsumgebungen, hebt besonders die Bedienoberfläche und die 
Integrationskontrolle für CASE-Werkzeuge sowie die Datenintegration hervor. Mit 
dem OSCE-System (Open Systems CASE Environment) bietet Siemens Nixdorf 
eine offene, verteilte, OSF/Motif-basierte Entwicklungsumgebung für SINIX an, 
die sich auf das ECMA-Konzept stützt. 


Ein Blick auf die heutige Spitzentechnologie bei den CASE-Werkzeugen in der 
Computerindustrie zeigt, daß die Einschränkungen bei der Integration von Werk- 
zeugen den breiteren Einsatz von CASE-Werkzeugen verhindern. Viele CASE- 
Werkzeuge sind fest in geschlossene Umgebungen integriert. Sie verfolgen ganz 
spezifische Ansätze und schließen weitgehend die Verwendung anderer, insbeson- 
dere kundenspezifischer Werkzeuge in der gleichen Umgebung aus. Eine flexible 
Konfigurierung der Software-Entwicklungsumgebung zur Anpassung an die unter- 
schiedlichsten Kundenbedürfnisse ist nur auf der Basis eines offenen Systems wie 
OSCE möglich. 


OSCE ist eine offene Software-Entwicklungsumgebung für 3GL-, 4GL- und 00- 
Programmiersprachen, die auf internationalen Standards (UNIX, NFS, OSF/Motif) 
basiert. Die Architektur von OSCE realisiert bereits in Teilen das ECMA-Referenz- 
modell für offene CASE-Umgebungen. Dieses Referenzmodell, das die Basis für 
die Entwicklung weiterer Standards auf dem CASE-Sektor sein soll, beschreibt ver- 
schiedene Aspekte: Integration von Bedienoberflächen, Inter-Tool-Kommunikation 
über Messages (beides in OSCE realisiert) sowie die Daten- und Prozeßintegration. 


OSCE unterstützt die effiziente Entwicklung komplexer Anwendungen in einer ver- 
teilten Entwicklungsumgebung und erlaubt die einfache Integration kundenspezifi- 
scher Werkzeuge. OSCE ermöglicht Interworking mit den Produkten SoftBench 
(Hewlett-Packard), OpenCase/ToolBus (INFORMIX), SDE (IBM) und anderen in 
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heterogenen Netzen. Insgesamt bietet OSCE alle wesentlichen Voraussetzungen für 
die Steigerung der Produktivität im Software-Entwicklungsprozeß. OSCE besteht 
aus den Komponenten OSCE-ToolBus und dem optionalen OSCE-Encapsulator. 


OSCE-ToolBus 


Allgemeine Eigenschaften 


In der Basiskonfiguration bietet OSCE die komfortable Unterstützung des Editier- 
Compilier-Zyklus für C, C++, FORTRAN und Pascal, außerdem Funktionen des 
Konfigurations-Managements und für die Kommunikation im Team. Die wesentli- 
chen Eigenschaften des Systems werden in den folgenden Abschnitten beschrieben. 


Objektmanagement-Dienste 


Kommunikations- 
Dienste 


Abbildung 5-3: Das in OSCE (SINIX) realisierte ECMA CASE-Referenzmodell. 


Kommunikation der Werkzeuge 


Die Werkzeuge kommunizieren über einen Broadcast Message Server (BMS) mit- 
einander. Das erlaubt eine weitgehende Automatisierung von Verfahrensabläufen 
und damit ein aufgabenorientiertes Arbeiten. Für den Anwender steht nicht mehr so 
stark im Vordergrund, welche Kombination von Werkzeugen er zur Erledigung ei- 
ner bestimmten Aufgabe braucht. Vielmehr kann er sich voll auf seine eigentlichen 
Aufgaben im Entwicklungsprozeß konzentrieren. 
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Verteilte Verarbeitung 


OSCE unterstützt die Verarbeitung aller Daten im UNIX-Netz. Zur Bearbeitung der 
Daten können beliebige OSCE-Werkzeuge auf verschiedenen Rechnern im Netz 
genutzt werden. Die Ausgabe eines Werkzeugs kann auf jedes Ausgabegerät im 
Netz umgelenkt werden. Die Arbeiten mehrerer Entwickler an einem Projekt kön- 
nen mit den integrierten Funktionen des Konfigurations-Managements koordiniert 
werden. Es können auch Server-Konzepte, wie z.B. File-Server oder Compile-Ser- 
ver, realisiert werden. 


Bedienoberfläche 


Die in OSCE integrierten Werkzeuge verfügen über eine einheitliche und leicht be- 
dienbare grafische Benutzerschnittstelle auf der Basis von OSF/Motif. Ein speziel- 
ler Help Manager steht zur komfortablen Ausgabe von Online-Hilfsinformationen 
zu den OSCE-Werkzeugen zur Verfügung. Die Menüs dieser Werkzeuge können 
durch den Benutzer erweitert werden, so daß eigene Werkzeuge aus den vorhande- 
nen heraus aufgerufen werden können. 


Integrierte Werkzeuge 
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Bereits in der Basiskonfiguration enthält OSCE eine Reihe leistungsfähiger Werk- 
zeuge, die im folgenden beschrieben werden. 


Tool Manager 


Der Tool Manager erlaubt das Starten und Beenden von Werkzeugen und gibt Aus- 
kunft über den Status der momentan aktiven Werkzeuge. Außerdem erlaubt er das 
Abspeichern und Wiederherstellen von Werkzeugkonfigurationen. 


Development Manager 


Mit dem Development Manager kann man sich einen Überblick über Dateisysteme 
(inklusive verteilter Dateisysteme) verschaffen. Außerdem unterstützt er die objekt- 
orientierte Verarbeitung der gespeicherten Daten. Er verfügt über einen Anschluß 
an das integrierte Konfigurations-Managementsystem, das entweder sccs- oder rcs- 
basiert sein kann. Von diesem Punkt aus können auch weitere wichtige Funktionen 
anderer OSCE-Werkzeuge, wie z.B. Static Analyzer oder Program Builder, aufge- 
rufen werden. 
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Program Builder 


Der Program Builder erlaubt das automatische Generieren von Makefiles sowie de- 
ren anschließende Ausführung. Bei der Ausführung von Makefiles werden Fehler- 
meldungen in einem eigenen Fenster angezeigt. Nach Selektion einer Fehlermel- 
dung (mit Mausklick) wird automatisch der Editor aktiviert und zeigt die fehlerhafte 
Zeile im betroffenen Programmcode an, so daß der Fehler unmittelbar korrigiert 
werden kann. 


Program Editor 


OSCE hat einen eigenen grafischen, syntaxsensitiven Editor. Wenn eine Datei in 
OSCE geändert wird, wird der geänderte Dateiinhalt automatisch in allen Fenstern, 
die auch die Datei anzeigen, dargestellt. Der Editor in OSCE kann konfiguriert wer- 
den. So können beispielsweise die Editoren MAXed, vi oder emacs eingesetzt wer- 
den. 


Static Analyzer 


Mit Hilfe des Static Analyzer kann in OSCE nach Definitionen, Deklarationen von 
Funktionen und Variablen sowie nach Referenzen von Funktionen und Variablen 
gesucht werden. Der betreffende Programmcode wird dann automatisch im Editor 
angezeigt. Die Funktionen des Static Analyzers können auch aus dem Editor heraus 
aufgerufen werden. Insbesondere bedeutet das, daß der Static Analyzer eine sehr ef- 
fiziente Unterstützung der Analyse von Programmstrukturen vorhandener Program- 
me anderer Entwickler anbietet. 


Mail 


Die Einbettung von mailx als OSCE-Werkzeug erlaubt dem Entwickler einen kom- 
fortablen Zugang über die grafische Bedienoberfläche und Menüs zu Mail-Funktio- 
nen und erleichtert so die Kommunikation im Team. 
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OSCE-Encapsulator 


OSCE stellt auch eine Integrationsplattform für die Integration von Standard- 
UNIX-Werkzeugen oder kundenspezifischen Werkzeugen in die Entwicklungsum- 
gebung dar. Das Integrationswerkzeug dafür ist der OSCE-Encapsulator. Mit dessen 
Hilfe hat der Anwender die Möglichkeit, z.B. Standard-UNIX-Programme (find, 
grep, usw.) oder eigene Werkzeuge zu integrieren. Kommando- und terminfo-ba- 
sierte Anwendungen erhalten so eine moderne Fensteroberfläche, ohne daß Ände- 
rungen im Sourcecode notwendig werden. Über eine offengelegte Programm- 
schnittstelle (C/C++) können auch vorhandene OSF/Motif-Anwendungen integriert 
werden. Durch Nutzung des vorhandenen Triggermechanismus auf der Basis von 
Events kann der Software-Entwicklungsprozeß weiter rationalisiert werden, z.B. 
durch Automatisierung immer wiederkehrender Abläufe. 


OSCE-Erweiterungen 
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Mit dem Produkt OSCE-Link besteht die Möglichkeit, den Komfort und die hohe 
Funktionalität von OSCE sowie von anderen in OSCE integrierten Werkzeugen 
auch für Entwicklungen im BS2000 zu nutzen. Daneben bietet Siemens Nixdorf 
eine Reihe von integrierten Werkzeugen für OSCE an. Hier sind insbesondere die 
Produkte I4GL for ToolBus zur Unterstützung der INFORMIX-4GL-Anwendun- 
gen und der C++ Developer als grafischer Klassenbrowser für C++ zu nennen. Wei- 
tere Beispiele sind KMS-X, DBX und MAXed. Die Liste dieser Werkzeuge wird 
ständig erweitert. 
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6 Systemverwaltung und Netzmanagement 


Der Einsatz von Rechnern und Netzwerken in entscheidenden Funktionen in Unter- 
nehmen, Behörden, öffentlichen und sonstigen Einrichtungen wächst zusehends. 
Das bedeutet, daß Systemfehler und Fehler in Netzwerken zu nicht vertretbaren 
Verzögerungen bei Lieferungen und im Service führen, Produktionseinbußen und 
Wettbewerbsnachteile nach sich ziehen und damit auch zu finanziellen Verlusten 
des Unternehmens führen. Diese Situation stellt hohe Anforderungen an die Verfüg- 
barkeit solcher Systeme. Fehlerdiagnose und Störungsbeseitigung werden jedoch 
durch Größe und Komplexität der Systeme und Netze sowie durch die örtliche Ver- 
teilung der einzelnen Komponenten erheblich erschwert. 


Geringe Durchsatzraten und lange Wartezeiten für Anwender sind häufig auf Eng- 
pässe bei den Ressourcen zurückzuführen. Diese Engpässe müssen rechtzeitig er- 
kannt und behoben werden, zum Beispiel durch eine Neukonfigurierung des Netzes. 


Die Aufgaben der Systemverwaltung und des Netzmanagements reichen von der 
Planung und Konfiguration über Lastmessung, Erstellen von Statistiken, Fehlerdia- 
gnose und Fehlerbeseitigung bis hin zur Software-Freigabe, ihrer Verteilung und 
Verwaltung. Systemverwaltung und Netzmanagement umfassen die Mechanismen, 
Werkzeuge und Produkte, die erforderlich sind, um Systeme und Netze zu steuern 
und zu überwachen. 


Systemverwaltung 


Die Aufgaben eines Systemverwalters erstrecken sich auf alle Phasen der Laufzeit 
eines Rechners. Sie reichen von der Installation des Systems über die Wartung wäh- 
rend der Laufzeit bis zum Hinzufügen von Komponenten zum existierenden Sy- 
stem. Typische Aktivitäten in den einzelnen Phasen sind: 
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OA&M 
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® Installation 
Die erste Aufgabe besteht darin, die Hardware und Software des Systems zu 
konfigurieren. Das heißt, die Basis-Software einzubringen und das System an 
existierende Wide-Area- oder Local-Area-Netzwerke anzuschließen. 


® Wartung während des Betriebs 
Dies umfaßt präventive Wartungsmaßnahmen wie das Überwachen des Dateis- 
systems oder das Anlegen von Sicherungen. Hinzu kommt eine Reihe von Auf- 
gaben wie das Eintragen von neuen Benutzern, das Installieren von neuer An- 
wender-Software und vieles andere mehr. 


Installieren von neuen Hardware-Komponenten 

Wenn neue Hardware erworben wurde, liegt es in der Verantwortung des 
Systemverwalters, diese Geräte anzuschließen und zu konfigurieren, ohne den 
laufenden Betrieb signifikant zu beeinträchtigen. 


Die OA&M-Schnittstelle (Operation, Administration and Maintenance) des 
SINIX-Systems ist ein Zugang zu den wesentlichen Verwaltungsfunktionen des Sy- 
stems. OA&M ist eine zeichenbasierte, menü- und maskenorientierte Oberfläche, 
die leicht zu erlernen und anzuwenden ist. Zur Zeit werden mit der OA&M-Soft- 
ware eine deutsche und eine englische Version ausgeliefert. Andere Sprachvarian- 
ten lassen sich ohne Änderung der Bedienoberfläche erzeugen. 


Unter anderem bietet OA&M folgende Funktionen an: 

® Benutzerverwaltung 

® Verwaltung von Dateisystemen 

® Einstellen von Systemparametern (z.B. Uhrzeit) 

® Performance-Analysen, wie etwa den CPU-Zeitverbrauch des Systems 
® Anwenderschnittstelle zur Konfigurierung der Hardware 


Zusätzlich zu diesen Standardfunktionen bietet OA&M eine offene Schnittstelle an, 
über die sich weitere Pakete in die Anwenderschnittstelle integrieren lassen, wie 
z.B. die Verwaltung des Sicherungssystems Backup oder des Siemens Nixdorf 
SPOOLss (siehe Seite 104 in diesem Kapitel und im Abschnitt „SPOOL: Drucken in 
Systemen mit verteilter Verarbeitung” auf Seite 130). 


Config 
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Config ist ein Konfigurationssystem zur komfortablen Hardware-Konfigurierung. 
Unter Konfiguration von Hardware versteht man die Gesamtheit der Verwaltungs- 
tätigkeiten, die notwendig sind, um periphere Geräte an einen Rechner anzuschlies- 
sen und zu betreiben. Das Anschließen von Peripheriegeräten ist eine der komple- 
xesten Aufgaben der Systemverwaltung. Standardisierte Abläufe und 
Verfahrensweisen sind dabei nicht möglich, weil es eine Vielzahl unterschiedlicher 
Geräte gibt, sowie eine große Zahl von Anschlußmöglichkeiten und verwendbaren 
Protokollen. Die Hauptaufgabe bei der Konfiguration von Hardware besteht darin, 
die unterschiedlichen Systemparameter konsistent zu halten. Geräte müssen einge- 
stellt (z.B. landesspezifische Tastaturtabellen laden) oder am Rechner eine Reihe 
von Anpassungen durchgeführt werden (z.B. die Pflege der Systemdatei /etc/hosts 
beim Anschluß von X-Terminals). So sind folgende Schritte (neben anderen) aus- 
zuführen, um einen Drucker an einen Rechner anzuschließen: 


® Eintragen des Drucker in die Konfigurationsdatei des Spoolers (Druckertyp, 
verwendete Emulation, verwendete Code-Tabellen, usw.) 


® Anlegen eines /dev-Knotens mit einer bestimmten Major- und Minor-Geräte- 
nummer. Diese sind abhängig von der verwendeten Systemschnittstelle und der 
verwendeten Kanalnummer. 


® Einstellen der rry-Parameter für den Knoten. Diese sind abhängig von der ver- 
wendeten Systemschnittstelle und dem angeschlossenen Druckertyp. 


® Zuordnen des/dev-Knotens für den jeweiligen Drucker in Beschreibungsdateien 
des Spool-Systems. 


Die einzustellenden Parameter sind nicht immer die gleichen. Sie sind abhängig 
vom Drucker, von der benutzen Anschluß-Schnittstelle, von der Software, die zum 
Betrieb des Druckers eingesetzt wird, und anderem mehr. 


Das Beispiel zeigt, daß das Einstellen gültiger Geräte- und Systemvariablen be- 
stimmten Bedingungen entsprechen muß, wenn ein fehlerfreies Verhalten des Sy- 
stems gewährleistet sein soll. Diese Bedingungen legen für korrekte Systempara- 
meter Wertebereiche fest und bestimmen die Abhängigkeiten zwischen den 
einzelnen Systemparametern. Die Zusammenhänge sind oft so komplex, daß nur 
Systemspezialisten in der Lage sind, ohne Software-Unterstützung eine fehlerfreie 
Konfiguration von Hardware-Komponenten vorzunehmen. 
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Das Ziel von Config ist es, die für das Anschließen und Konfigurieren von periphe- 
ren Geräten notwendigen Aufgaben so weit wie möglich zu automatisieren, um so 
Parameter fehlerfrei und konsistent einzustellen. Config erlaubt es, sowohl die Wer- 
tebereiche und Abhängigkeiten von Systemparametern als auch die Struktur der an- 
geschlossenen Peripherie extern zu beschreiben. Damit ist es möglich, neue Geräte 
in das Konfigurationssystem einzuführen und die Eigenschaften bestehender Geräte 
zu verändern. 


Architektur und Schnittstellen 
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Bei dem Design des Konfigurationssystems Config wurden folgende Anforderun- 
gen berücksichtigt: 


® Das Konfigurierungswerkzeug soll erweiterbar und anpassungsfähig sein. Das 
Konfigurierungswerkzeug muß sich leicht an die verschiedenen peripheren Ge- 
räte und an neue Hardware anpassen lassen. Sowohl die Definition von Konfi- 
gurationsabläufen entsprechend der bestehenden Hardware als auch die Anpas- 
sung des Werkzeugs selbst an neue Zentraleinheiten und neue Betriebssystem- 
versionen muß leicht und ohne großen Aufwand durchführbar sein. Aus diesem 
Grund sind die Konfigurationsabläufe von der aktuellen System-Hardware zu 
trennen und in einer speziellen Regelsprache zu implementieren. 


® Das Konfigurierungswerkzeug soll grafische und alphanumerische Bedienober- 
flächen unterstützen. 


® Das Konfigurierungswerkzeug soll es ermöglichen, Konfigurationen für Fremd- 
rechner auf einem zentralen Konfigurationsrechner vorzubereiten. Derartige 
Konfigurationsmodelle können über ein Service-Netz zu den Kundenrechnern 
transferiert werden oder vor Ort von einem Service-Techniker manuell eingele- 
sen werden. Das bedeutet für die Architektur des Systems, daß die Konfigurati- 
onsdaten nicht unmittelbar in das System übernommen werden dürfen. Die Spe- 
zifikation der Konfiguration und die Übernahme der Konfigurationsdaten in das 
System sollen voneinander getrennt werden. 
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Abbildung 6-1: Die Systemarchitektur von Config (SINIX). 


Diese Anforderungen führen zu einer Systemarchitektur, wie sie in Abbildung 6-1 
dargestellt ist. 
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Die Benutzerschnittstelle zeigt dem Benutzer die Konfigurationsdaten. Diese sind 
objektorientiert angelegt. Die Objekte sind in einem Objektbaum hierarchisch an- 
geordnet, der den logischen Zusammenhang der zu konfigurierenden Objekte wi- 
derspiegelt, und sowohl auf der alphanumerischen Oberfläche als auch innerhalb 
der grafischen Oberfläche angeboten wird (Siehe Abbildung 6-2). 


Terminal-Server 


Abbildung 6-2: Beispiel eines Config-Objektbaums 


Der Anwender kann innerhalb des Baums mit verschiedenen Methoden navigieren. 
Er kann die angezeigten Konfigurationsobjekte und deren Eigenschaften mit den 
Operationen add, remove und open verändern. 


Die zentral steuernde Komponente des Systems ist der Objekt-Editor (Object Edi- 
tor - OED). Über die Kommandoschnittstelle (Command Line Interface - CLI) 
empfängt er von der Bedienoberfläche Befehle zur Manipulation des Objektbaums 
(Data Object - DO). Kontrollinformationen und Ausgabedaten gibt der Objekt-Edi- 
tor an die Bedienoberfläche zurück. Operationen am Objektbaum dürfen nur dann 
durchgeführt werden, wenn die Konsistenz des Datenbestandes gesichert ist. Der 
Objekt-Editor verwendet zwei externe Datenstrukturen, um die Konsistenz zu prü- 
fen: 
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Hardware-Beschreibungsdatei (UID) 


In dieser UID-Datei (User Interface Definition) ist die Struktur der Hardware be- 
schrieben, die konfiguriert werden soll. Es können die Abhängigkeiten von Werten 
beschrieben werden und es stehen Sprachmittel zur Verfügung, mit denen die Kon- 
sistenz der Daten geprüft werden kann. Die Funktionalität der Beschreibungsspra- 
che erlaubt es, die Konfigurationsobjekte auf hierarchische Weise zu beschreiben. 


Datenobjekte (DO) 


Die DO-Dateien sind eine semantische Kopie der aktuellen Systemparameter und 
beschreiben vollständig die Hardwarekonfiguration des Systems. Die aktuellen Sy- 
stemwerte sind entsprechend der UID-Beschreibung strukturiert. Man kann sich die 
Datenobjekte als eine Instanziierung der UID-Dateien vorstellen. Das Datenobjekt 
wird entweder manuell durch den Benutzer erzeugt oder automatisch durch das 
Ausführen eines Analysierungslaufs. Die Bearbeitung der Systemparameter durch 
den Objekt-Editor verändert die Werte in den Datenobjekt-Dateien. Nach Beenden 
der Konfigurationssitzung (oder während der Sitzung durch Ausführen eines ent- 
sprechenden Kommandos) werden die in den Datenobjekten vorhanden Werte in 
das System übernommen. 


Mit diesen beiden Strukturen teilt der Objekt-Editor der Benutzerschnittstelle wäh- 
rend der Laufzeit alle notwendigen Präsentationsinformationen mit. Die Informa- 
tionen umfassen: 


® Attribute des aktuellen Objekts sowie gültige Wertebereiche pro Attribut. Die 
Entscheidung, welches Präsentationsmittel zur Darstellung eines Attributwertes 
verwendet wird, wird autonom von dem Benutzerschnittstellen-Modul getrof- 
fen. 


® Fehlermeldungstexte und Hilfetexte. Durch die Verwendung von NLS (XPG3) 
lassen sich verschiedene Sprachvarianten erzeugen. 


® Der Objekt-Editor stellt bei der Eingabe neuer Attributwerte über die Bedien- 
oberfläche die Korrektheit der neuen Werte her, und zwar mit Hilfe der aktuellen 
Werte in den DO-Dateien und der in der UID formulierten Konsistenzprüfun- 
gen. Fehlerhafte Werte werden zurückgewiesen oder in das Datenobjekt über- 
nommen, anschließend wird das gesamte Datenobjekt als für einen Erzeugungs- 
lauf nicht geeignet gekennzeichnet. 


103 


6 Systemverwaltung und Netzmanagement 


Backup 


SINIX-Systeme haben exzellente Netzwerkeigenschaften und sind deshalb oft in 
Netzwerken installiert. Das macht den Einsatz von verteilten Ressourcen in einem 
Umfang möglich, der vorher nicht möglich war. In diesem Zusammenhang ist der 
Einsatz von verteilten Datensicherungsdiensten eine unabdingbare Voraussetzung 
für die heutige Systemverwaltung. 


Die Verwendung von verteilten Ressourcen meint nicht einfach den Zugriff auf ent- 
fernte Daten und Geräte. Um die notwendige professionelle Datensicherung in ei- 
nem Netzwerk durchzuführen, ist die Integration von Diensten wie netzwerkweite 
Auftragsverwaltung, Geräteverwaltung, Medienverwaltung und Benutzerverwal- 
tung genauso wichtig wie leichte, flexible Konfiguration und ein hoher Grad an Ver- 
fügbarkeit. In einer kommerziellen Umgebung sind Kriterien wie einfache Bedie- 
nung, effektive Meldungsmechanismen, hoher Datendurchsatz, 
Kostenminimierung und Sicherungsläufe ohne Bediener-Eingriff schon immer ent- 
scheidend. Dieses Szenario beschreibt die Anforderungen an Backup, das netz- 
werkweite Datensicherungswerkzeug für SINIX-Systeme. 


Die Architektur 
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Die Architektur von Backup basiert auf einem Client-Server-Modell, das ein Maxi- 
mum an Flexibilität ermöglicht. Die einzelnen Komponenten des Werkzeugs Kön- 
nen auf separaten Systemen laufen, die in ein Netzwerk eingebunden sind. Der Un- 
terschied zwischen lokalen und entfernten Operationen ist für den Client aufgrund 
der einheitlichen Syntax nicht sichtbar. 


Das Herz von Backup ist eine verteilte Datenbank. Diese Datenbank enthält alle für 
die Datensicherung relevanten Informationen über das Netzwerk in Form von Ob- 
jekten. Nur ein System im Netz hat zu jeder Zeit schreibenden Zugriff auf die Da- 
tenbank. Dieses System ist der sogenannte „Backup Master“. Alle Änderungen in 
der Datenbank werden vom Master-Rechner ausgeführt. Auf diese Weise ist die 
Konsistenz der Daten in der Datenbank gewährleistet. Damit allen beteiligten Sy- 
stemen im Netz ein schneller Lesezugriff auf die Objekte garantiert werden kann, 
erhält jedes System eine Kopie der Datenbank. Fällt der Rechner mit der Master- 
Datenbasis aus, übernimmt ein beteiligter Rechner die Rolle des Masters. Dies ge- 
schieht auf der Basis einer festgelegten Priorität. 
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Abbildung 6-3: Die Architektur von Backup (SINIX). 


Gleiche Sicherungsgeräte sind in Gruppen zusammengefaßt und werden von einem 
Geräte-Server verwaltet. Der Geräte-Server erlaubt parallele Sicherungsaufträge, 
und die Lastverteilung erfolgt auf Sicherungsgeräten der Gruppe. Der Geräte-Ser- 
ver verwaltet eine Warteschlange der Sicherungsaufträge mit einer Supervisor- 
Nummer. Er koordiniert die Sicherungsaufträge und stellt die Verbindung zwischen 
dem Daten-Server und dem Supervisor her. Die Lastverteilung wird durch die Auf- 
teilung der laufenden Sicherungsaufträge auf den Supervisor erreicht. Alle Informa- 
tionen, die Datenserver und Supervisor brauchen, werden von der Datenbank des 
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Geräte-Servers zur Verfügung gestellt. Die erforderlichen Bedieninteraktionen oder 
Ereignismeldungen des Supervisors werden dem Client über den Geräte-Server zur 
Verfügung gestellt. 


Backup gewährleistet eine flexible Sicherheitsprüfung über Zugriffsberechtigungen 
auf Daten, Sicherungsgeräte und Sicherungsmedien. Ein Identifizierungs-Code auf 
dem Sicherungsmedium gewährleistet die Verwendung des richtigen Sicherungs- 
mediums. 


Ein Daten-Server generiert einen Datenstrom der Daten, die gesichert werden sol- 
len. Sowohl Vollsicherungen als auch inkrementelle Sicherungen auf verschiedenen 
Stufen sind möglich. Der Daten-Server bietet die Möglichkeit, die Daten zu kom- 
primieren. Darunter liegt eine Schnittstelle, die es erlaubt, den Datenstrom unter- 
schiedlich aufzubereiten. Auch Nachfolgebehandlungen sind zugelassen. 


Jedes Sicherungsgerät im Netzwerk hat seinen eigenen Supervisor. Er übernimmt 
die Steuerung des Geräts und unterstützt gerätespezifische Eigenschaften, so daß 
eine Schnittstelle unabhängig von dem spezifischen Gerät bedient werden kann. Zur 
Zeit gibt es Supervisoren für Magnetbandgeräte, Magnetbandkassettengeräte, Vi- 
deo-8-Systeme, Diskettenlaufwerke und Jukebox-Laufwerke mit optischen Platten. 


Der Client repräsentiert die Schnittstelle zum Systemverwalter. Er ist verantwort- 
lich für die Zugriffs- und Berechtigungskontrolle sowie für die Syntaxprüfung von 
Benutzerkommandos. Der Client kann in zwei verschiedenen Betriebsarten gestar- 
tet werden: 


® Hintergrund 
Der Sicherungsauftrag wird in die Warteschlange gestellt. Dabei gibt es keinen 
Dialog mit dem Systemverwalter. 


® Interaktiv 
Der Systemverwalter kann die laufenden Aufträge von seinem Terminal aus 
steuern. 
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Für alle Aktionen, die für die Steuerung und Konfiguration des Datensicherungs- 
werkzeugs ausgeführt werden, stehen dem Benutzer drei verschiedene Möglichkei- 
ten zur Verfügung: 


® Shell-Kommandos 
® FMLI-Menü für alphanumerische Terminals 
® OSF/Motif-Schnittstelle 


In die Struktur der Schnittstelle sind ausführliche Hilfefunktionen integriert. Eine 
mehrsprachige Unterstützung ist geplant. 


Backup ist als Werkzeug für die Datensicherung in kommerziellen Netzwerken 
konzipiert. Es erlaubt die netzwerkweite Festlegung von Sicherungsbereichen und 
Sicherungszeiten und unterstützt eine große Anzahl verschiedener Sicherungsgerä- 
te. Über das Medienmanagement stellt es sicher, daß gültige Datensicherungen 
nicht durch Fehler überschrieben werden. Backup entlastet den Systemverwalter 
bei seinen täglichen Sicherungsaufgaben. 
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Heterogenes Netzmanagement in SINIX: TRANSVIEW 


Übersicht 
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In zunehmenden Maße werden in Unternehmen und Organisationen Netzwerke mit 
unterschiedlichen Rechnern eingesetzt. Für solche heterogenen Netze gibt es der- 
zeit nur wenige integrierte Managementlösungen. Die Managementaufgaben in 
heutigen heterogenen Netzen müssen für jedes Teilnetz mit herstellerspezifischen 
Werkzeugen (Kommandosprachen, Verwaltungswerkzeuge) gelöst werden. Erfor- 
derlich ist ein übergreifendes Netzmanagement für heterogene Netzwerke mit einer 
einheitlichen Sicht auf alle Netzwerk- und Systemkomponenten, die zu steuern und 
zu überwachen sind. Voraussetzungen dafür sind: 


® die Definition international standardisierter Protokolle und Dienste für den Aus- 
tausch von Daten und Managementinformationen 


® die Definition von Objekten, unabhängig von den Eigenschaften der Hersteller- 
systeme 


® die Definition von Managementeigenschaften 


Dieser Bedarf wird in Zukunft steigen, vor allem mit der Verbreitung von verteilten 
Systemen, die sehr komplexe Interaktionen zwischen Netzknoten hervorrufen. 


Die Familie der TRANSVIEW-Produkte von Siemens Nixdorf unterstützt die Netz- 
werksteuerung, die Überwachung und die Software-Verteilung. Aufbauend auf 
langjährigen Erfahrungen auf dem Gebiet des Netzmanagements und der System- 
verwaltung hat Siemens Nixdorf mit TRANSVIEW ein modernes und flexibles 
Verwaltungssystem geschaffen, das die bestehenden OSI-Managementstandards 
und De-facto-Industriestandards (OSF/DME, SNMP, TCP/IP, SNA) unterstützt. 
TRANSVIEW-Produkte ermöglichen es, bestehende und zukünftige Systeme in ho- 
mogenen und heterogenen Netzwerken effektiv zu unterstützen. 


TE 


|| 


TRANSVIEWP- 


TRANSVIEW-ÄTRANSvIEwW- 
MIB 


NMC SNMP 


| 


OSI-Agents 


Fon] 


„TRANSVIEW-NMC*“- 
Agents 


Abbildung 6-4: TRANSVIEW Manager und Agents 
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Die angebotenen Netzmanagement-Operationen umfassen Standard-Management- 
Anwendungen zur Netz- und Systemdefinition, Umkonfigurierung, Netz-, System- 
und Anwendungsüberwachung sowie die Ermittlung von Leistungsdaten. Die für 
TRANSVIEW geplanten Funktionen und Möglichkeiten werden in mehreren Stu- 
fen implementiert. In der ersten Stufe liegt der Schwerpunkt auf der Realisierung 
von Funktionen aus den Bereichen Netzüberwachung, Konfiguration, Fehlerbe- 
handlung und Performance-Management. 
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Das TRANSVIEW-Netzmanagement basiert auf dem Manager-Agent-Prinzip. Es 
steuert und überwacht von einer zentralen Stelle aus eine Vielzahl unterschiedlicher 
Agents, die in Agent-Systemen lokalisiert sind. 


Manager und Agent-Systeme kommunizieren auf der Basis folgender Manage- 
ment-Protokolle: 


® NMCP (Network Management Communication Protocol), einer Erweiterung 
des vorhandenen S3-Protokolls für den homogenen Betrieb mit Siemens-Nix- 
dorf-Systemen (SINIX-, BS2000-, PDN- und INCA-Systemen). 


® CMIP (Common Management Information Protocol) zur Unterstützung hetero- 
gener Netze auf der Basis von OSI-Managementstandards. 


® SNMP (Simple Network Management Protocol) zur Unterstützung TCP/IP- 
Netzen. 


TRANSVIEW führt die Übertragung von Management-Informationen unabhängig 
vom Transportsystem durch. Unterstützt werden z.B. NEA, ISO, TCP/IP und SNA- 
Netze. 


Zu TRANSVIEW gehören folgende Produkte für Netz-, System- und Anwendungs- 
management: 


® TRANSVIEW-NMC 
® TRANSVIEW-SNMP 
® TRANSVIEW-DSM 
® TRANSVIEW-DAME 


Zusätzlich zu diesen Produkten gehören auch die TRANSDATA -Netzmanagement- 
Produkte zur TRANSVIEW-Produktpalette. Besonderes Augenmerk wurde darauf 
verwendet, existierende und erprobte Produkte in das TRANSVIEW-Konzept ein- 
zubinden, die harmonisch mit den neuen Produkten zusammenarbeiten. Mit 
TRANSIT-NVS (NetView Support) werden SINIX-Systeme in das SNA-Manage- 
ment eingebunden (über Entry Point und Service Point). TRANSVIEW-NMC und 
TRANSVIEW-SNMP werden in Zukunft mit NetView über TRANSIT-NVS 
kommunizieren. 
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TRANSVIEW wird ständig weiterentwickelt, um dem Bedarf des Marktes entge- 
genzukommen. Ein wichtiges Ziel ist die Integration funktionaler Managementele- 
mente, die bislang auf eigenen Plattformen liefen. Die nächsten Versionen von 
TRANSVIEW unterstützen weitere Agent-Systeme von Siemens Nixdorf und neue 
Managementfunktionen, wie z.B. license. Schritt für Schritt wird TRANSVIEW die 
OSF/DME-Spezifikationen zur Vereinheitlichung von System- und Netzmanage- 
ment verwirklichen. Dies trifft teilweise heute schon für DME-spezifizierte 
Schnittstellen zu. 


TRANSVIEW-NMC 


TRANSVIEW-NMC ist das Netzmanagement-Produkt von Siemens Nixdorf, das 
im Network Management Center (NMC) eingesetzt wird. Die zentrale Komponente 
von TRANSVIEW-NMC ist die offene Plattform. Sie ist das integrierende Element 
für alle Anwendungen, mit denen die umfassenden Funktionen von TRANSVIEW- 
NMC realisiert werden. Der Zugang besteht über das TRANSVIEW-API INMS 
(Interface Network Management Service), die Schnittstelle zu den Netzmanage- 
ment-Diensten und dem X/Open XMP-API (X/Open Management Protocol API). 
TRANSVIEW berücksichtigt die wichtigsten Merkmale der auf OSI basierenden 
offenen Managementarchitektur. Das NMC ist ein SINIX-System, das als Manager 
verschiedene Agent-Systeme steuert und überwacht. Es steht eine konfigurierbare, 
objektorientierte Bedienoberfläche zur Verfügung, die auf dem X Window System 
und SINIX/windows basiert. 


Die wesentlichen Bestandteile des NMC sind: 

® der Kernel (zentrales Element der TRANSVIEW-Plattform) 

® die Netzbausteine für die Kommunikation von Management-Informationen 
® die grafische Bedienoberfläche 

® die Standard- oder betreibereigenen Netzmanagement-Anwendungen 

® die zentrale Datenbank 


® das Meldungswesen 
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Die meisten Funktionen von TRANSVIEW-NMC sind über Netzmanagement-An- 
wendungen verfügbar: 


® Network Monitor 


® Performance Monitor 


® Session Monitor 
® Netzdefinition 
® Netzkonfiguration für Systeme 


Die Standardfunktionen können durch betreibereigene Funktionen ergänzt werden, 
um z.B. das Netzmanagement-System auf die Bedürfnisse des Betreibers zuzu- 
schneiden. Über das objektorientierte, offene Management-API INMS (Interface 
Network Management Service) kann auf die zentrale Datenbank zugegriffen wer- 
den. Die Basis-Datenbanksysteme sind das Enterprise Repository Management Sy- 
stem (ERMS) und das Datenbanksystem INFORMIX. 


TRANSVIEW unterstützt in der ersten Stufe durch folgende Netzmanagement- 
Funktionen die Systeme anderer Hersteller, die mit dem NMC über das standardi- 
sierte OSI NM-Protokoll CMIP (Common Management Information Protocol) 
kommunizieren können: 


® Network Monitor 
® Netzdefinition 
® grafische Bedienoberfläche 


Dabei können Objekte angesprochen werden, die von ISO oder dem NM-Forum 
festgelegt wurden. Außerdem wendet TRANSVIEW die von EWOS (European 
Workshop for Open Systems) festgelegten Profildefinitionen für das Management 
Information Protocol MIP (AOMI12) an. 
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Globale Struktur 


Die Architektur, die Informationsstruktur und die wichtigen internen Mechanismen 
sind wesentlich geprägt durch die OSI-Netzmanagement-Standards von ISO und 
CCITT sowie durch die Arbeiten des NM-Forums. Ein Beispiel dafür ist die Objekt- 
orientierung, die sich in der Benutzerschnittstelle (Programmierung und Bedien- 
schnittstelle), in der internen Struktur und in der Objektbibliothek zur Beschreibung 
eines TRANSDATA Netzes manifestiert. Die Objektbibliothek ist grundlegend für 
die konsistente Datenhaltung, deren Konzept sich an den OSI-Prinzipien der 
Management Information Base (MIB) zum Zugriff auf Management-Informationen 
orientiert. Die Struktur der Management-Informationen richtet sich nach den von 
ISO festgelegten Regeln (Structure of Management Information - SMI). Die von 
TRANSVIEW eingeführten Dienste entsprechen den bei ISO definierten CMIS- 
Diensten. Das von ISO definierte Verfahren für die Verteilung von Meldungen wird 
auch für die internen systemspezifischen Meldungen verwendet. Die Architektur 
von TRANSVIEW stimmt so im wesentlichen mit der von ISO definierten Netz- 
management-Architektur überein und legt die Regeln für die Struktur des TRANS- 
VIEW Management-Systems (Plattform, APIs, Module) fest. 
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Abbildung 6-5: Die Netzmanagement-Plattform 


In TRANSVIEW führen die Network Management Services (NMS) die Manage- 
mentfunktionen aus. Diese Dienste umfassen Empfang, Übertragung und Zustel- 
lung der Netzmanagement-Aufträge, der Auftragsergebnisse und Meldungen der 
Netzmanagement-Ereignisse. Dienstnutzer sind die Manager und Agents von 
TRANSVIEW. Zum Informationsaustausch zwischen Managern und Agents, die 
auf unterschiedlichen Systemen lokalisiert sind, verwendet TRANSVIEW die 
Netzkommunikationsdienste. Der Informationsaustausch erfolgt über Netzmanage- 
ment-Protokolle. Die mit NMS angebotenen Dienste stehen an der Schnittstelle 
INMS (Interface t6 Network Management Services) zur Verfügung. Die INMS ist 
eine offene Anwendungs-Programmierschnittstelle (APD). Sie kann von Standard- 
Netzmanagement-Anwendungen, die mit dem Produkt TRANSVIEW-NMC zur 
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Verfügung gestellt werden, wie auch von betreibereigenen Anwendungen benutzt 
werden. Die TRANSDATA-Objektbibliothek ist ein integraler Bestandteil von 
TRANSVIEW und wird zusammen mit TRANSVIEW ausgeliefert. Es stehen 
Werkzeuge zur Verfügung, mit denen sie erweitert werden kann. 


Im TRANSVIEW-NMC sind die Netzmanagement-Dienste als die Netzmanage- 
ment-Plattform implementiert. Die Plattform besteht aus dem Netzmanagement- 
Kernel und den Netzmanagement-Kommunikationsmodulen (Netzbausteine). Die 
Aufgaben des Kernels umfassen das Protokollieren und Zustellen von Aufträgen, 
Auftragsergebnissen und Ereignismeldungen an den jeweiligen Empfänger sowie 
die Berechtigungsprüfung. Die Netzbausteine ermöglichen den Zugang zu den Ob- 
jekten oder zu Netzmanagement-Informationen in entfernten Agent-Systemen 
durch die Nutzung von Netzmanagement-Protokollen. TRANSVIEW unterstützt 
verschiedene Agent-Systeme. Die mit der Plattform gebotenen Dienste stehen an 
der Programmschnittstelle INMS (Interface Network Management Service) zur 
Verfügung. Die nachfolgend aufgeführten Module nutzen diese Dienste zum Einho- 
len von Management-Informationen. 


Präsentationsmodule 


Diese umfassen den Baustein Desktop und anwendungsspezifische Präsentations- 
bausteine. Der Baustein Desktop ist die Arbeitsumgebung für den Netzbediener 
(z.B. grafische Darstellung der Netzkonfiguration, Anzeigen von Ereignissen im 
Netz, Verwaltung von Auftragsfenstern). 


Funktionsmodule 


Die Funktionsmodule sind Netzmanagement-Anwendungen. Sie bieten dem Netz- 
betreiber vielfältige Funktionen zur Steuerung und Überwachung der System- und 
Netzkomponenten, wie z.B. Auswertung und Aufbereitung von Netzmanagement- 
Informationen. TRANSVIEW stellt hier Standard-Anwendungen für allgemein 
nutzbare Einsatzfälle zur Verfügung, wie z.B. Netzdefinition, Netz-Monitor, Ver- 
bindungs-Monitor. 
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Zugriffsmodule 


Die Zugriffsmodule ermöglichen den Zugang zu den Netzressourcen und zu den 
Netzmanagement-Informationen. Bei Agent-Systemen sind dies die lokalen 
Netzressourcen, am NMC sind zusätzlich die in der zentralen Datenbank gespei- 
cherten und von den Netzmanagement-Anwendungen ermittelten Informationen 
verfügbar. 


TRANSVIEW-SNMP 


Neben den bei ISO definierten OSI-Management-Standards wurde im Rahmen der 
Internet Community mit SNMP (Simple Network Management Protocol) ein wei- 
terer Netzmanagement-Standard festgelegt. SNMP kann in heterogenen LANs 
(Ethernet, Token Ring, FDDI) eingesetzt werden, die mit dem Protokoll TCP/IP be- 
trieben werden. Das SNMP-Management basiert wie das OSI-Management auf 
dem Manager-Agent-Prinzip. Die wesentlichen Komponenten des SNMP-Manage- 
ments sind Manager, Agent und Management Information Base (MIB). Bei Sie- 
mens Nixdorf steht als Produkt, mit der die Management-Rolle realisiert wird, das 
TRANSVIEW-SNMP zur Verfügung. TRANSVIEW-SNMP läuft auf SINIX- 
Systemen und ist als erstes Produkt der TRANSVIEW-Familie auf dem Markt er- 
schienen. Es unterstützt eine Vielzahl von SNMP-Agents, wie z.B. Bridges, Router, 
Gateways, Hubs, SINIX-Systeme und BS2000-LAN-Kanaladaptoren. Alle aktuel- 
len SINIX-Systeme verfügen über SNMP-Agents. Sie unterstützen die komplette 
standardisierte MIB-II und sind über eine Programmschnittstelle erweiterbar für 
weitere standardisierte und private MIBs. 


TRANSVIEW-SNMP (Manager) 


TRANSVIEW-SNMP ist das Produkt von Siemens Nixdorf, mit dem die Manage- 
ment-Funktionalität realisiert wird. Die wesentlichen Elemente von TRANSVIEW- 
SNMP sind die SNMP-Protokollmaschine, eine Plattform, auf der Management- 
Anwendungen, wie z.B. Objekt-Management, Alarm-Management usw. aufsetzen 
können, und eine X Window und OSF/Motif basierte, komfortable Bedienoberflä- 
che. Bei dieser Struktur wurden die wichtigsten Merkmale einer offenen Manage- 
ment-Architektur berücksichtigt, wie sie auch bei ISO für das OSI-Management de- 
finiert wurde. 
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Abbildung 6-6: Das SNMP-Protokoll. 


Über vier Benutzerschnittstellen hat der Betreiber Zugang zur TRANSVIEW- 
SNMP-Plattform und damit die Möglichkeit, sein Management-System optimal an 
seine Bedürfnisse anzupassen: 


® Das Anwendungs-API zum Anschließen von Standard- und betreibereigenen 
Management-Anwendungen. 


Das API für den fernen Zugriff mit Zugriffsfunktionen auf Objekte in entfernten 
Agent-Systemen und zum Empfangen von Meldungen dieser Systeme. Über 
dieses API können neben SNMP weitere Protokollstacks, wie z.B. für CMIP 
oder für betreibereigene Protokolle, angesprochen werden. 


® Das Bedienoberflächen-API zur Gestaltung des Bildschirm-Layouts (Farben, 
Icons, Vordergrund, Hintergrund usw.) 


® Das Alarm-Management-API zur automatischen Reaktion auf Fehlerzustände. 
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Abbildung 6-7: Die TRANSVIEW-SNMP-Architektur. 


Funktionen von TRANSVIEW-SNMP 


TRANSVIEW-SNMP ist über eine grafische Bedienoberfläche auf der Basis von 
X Window und OSF/Motif zu bedienen. Diese Bedienoberfläche kann der Betreiber 
leicht selbst gestalten. Agents können über Icons aus der Icon-Bibliothek oder selbst 
erstellte Icons dargestellt werden. Für einen Agenttyp sind ein oder mehrere Icons 
verwendbar. Darüber hinaus können mit der Discovery-Funktion Netzkonfiguratio- 
nen automatisch erfaßt und verglichen sowie unbefugtes Eindringen festgestellt 
werden. 


118 


6 Systemverwaltung und Netzmanagement 


Die wichtigsten Funktionen von TRANSVIEW-SNMP sind: 


® Regelbasierte Fehlerbehandlung (Polling mit einstellbaren Intervallen, Fehler- 
gewichtung, Zustandsübergangsdiagramme für automatische Reaktionen, An- 
zeigen im Netz-Monitor, erweiterbare Management Information Base (private 
MIB) 


® Konfigurations-Management (Network Monitor zur Zustandsüberwachung, 
Definition von Netzen) 


® Performance-Management (Erzeugung von Auslastungsdaten als Grafiken, 
Listen oder Tabellen, Protokoll-Management) 


® Manager-Kaskadierung 

® Unterstützung des Produkts NetProbe 

® Bridge-Management 

® SQL-Schnittstelle zum Datenbanksystem INFORMIX 


SNMPbietet als Standard eine Zugriffskontrolle über die sogenannte „community”, 
die mit einem Paßwort vergleichbar ist. Zusätzlich ist der SINIX-Zugriffs- und Be- 
rechtigungsschutz gewährleistet. Die weitere Entwicklung von TRANSVIEW- 
SNMP umfaßt schwerpunktmäßig den Anschluß von NetView, komfortables Kon- 
figurieren und Steuern von Hubs sowie das komfortable Erstellen von Statistiken. 


TRANSVIEW-SNMP läuft sowohl eigenständig als auch im Verbund mit TRANS- 
VIEW-NMEC. Im Verbundbetrieb wird TRANSVIEW-SNMP vom TRANSVIEW- 
NMC aus gestartet und beendet. Seine Oberfläche ist in die von TRANSVIEW- 
NMC integriert. Außerdem können Alarmmeldungen von TRANSVIEW-SNMP an 
TRANSVIEW-NMC weitergeleitet werden, so daß das gesamte Netz von einem 
Terminal aus überwacht und gesteuert werden kann. 
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SNMP-Agents wickeln einerseits die Kommunikation über SNMP ab und greifen 
andererseits lesend und schreibend auf die Objekte ihrer Netzkomponenten zu. 
Netzkomponenten sind z.B. Bridges, Router, Hubs, aber auch SINIX-Systeme. 
Durch die Definition privater MIBs ist SNMP für Management- Aufgaben in belie- 
bigen Bereichen einsetzbar. Die getrennte Festlegung der Standards für das SNMP- 
Protokoll und die MIB hat auch die Software-Architektur des Siemens Nixdorf-Pro- 
duktes SINIX-SNMP-Agent geprägt: SNMP und MIB-II sind dabei in getrennten 
Modulen implementiert (Core Agent und Agent Extension), die über eine Pro- 
grammschnittstelle zusammenarbeiten. Über diese Programmschnittstelle können 
auch weitere MIB-Implementierungen angeschlossen werden. 


Der SINIX-Agent unterstützt die Standard-MIB-II. Der SNMP-Agent V1.0 ermög- 
licht zunächst den lesenden Zugriff auf eine Untermenge der in der MIB-II definier- 
ten Objekte. Eine Erweiterung, im SNMP-Agent V2.0 realisiert, unterstützt alle Ob- 
jekte mit lesendem und schreibendem Zugriff entsprechend den Festlegungen des 
MIB-II-Standards. Die Schnittstelle zwischen Core Agent und Agent Extension ist 
so angelegt, daß Agent Extensions dynamisch dazugebunden werden können. Dies 
hat den Vorteil, daß Agent Extensions entkoppelt vom Core Agent freigegeben wer- 
den können. Ein Siemens-Nixdorf-Produkt oder eine Anwendung, die über das 
SNMP-Management gesteuert und überwacht werden soll, enthält eine Agent Ex- 
tension, die als Bestandteil dieses Produkts ausgeliefert wird. Bei der Installation 
des Produkts wird seine Agent Extension automatisch an den bereits auf dem 
SINIX-System vorhandenen Agent angebunden und ist damit von einem Manager 
über das SNMP-Protokoll ansprechbar. 


Für die Definition von herstellerspezifischen MIBs hat sich Siemens Nixdorf von 
der Internet Assigned Numbers Authority (IANA) einen Knoten im Baum der welt- 
weit eindeutigen Objektnamen zuweisen lassen. Unter diesem Knoten werden die 
herstellerspezifischen Objekte angesiedelt. Siemens Nixdorf stellt auch seinen Kun- 
den unter dieser Nummer einen Unterbaum zur Definition von deren privater MIB 
zur Verfügung. 
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TRANSVIEW-DSM 


TRANSVIEW-DSM (Distributed Systems Management) umfaßt Funktionen zur 
Software-Verteilung, Software-Verwaltung und Software-Installation. Es kann auf 
einer Vielzahl von Betriebssystemen, wie z.B. SINIX, MS-DOS, MS-Windows, 
und OS/2, Software verteilen, installieren und verwalten. Das kann Software von 
Siemens-Nixdorf-Produkten sein, Software von Fremdherstellern oder Kunden- 
Software. Unter DSM dient ein Rechner im Netz als sog. MS (Managing System), 
das alle Informationen speichert und die Verwaltung durchführt. 


Der herausragende Vorteil von TRANSVIEW-DSM ist, daß geschulte und erfahre- 
ne System- und Netzwerkverwalter von einem Rechner aus Software installieren, 
verwalten und aktualisieren können, und Benutzer an anderen Systemen oder ande- 
ren Rechnern im Netz von der Durchführung dieser Aufgaben nicht betroffen sind. 
Diese können sich auf ihre Arbeit konzentrieren, was zur allgemeinen Produktivi- 
tätssteigerung beiträgt. 


TRANSVIEW-DAME 


Das Produkt TRANSVIEW-DAME (Dynamic Administration Management 
Environment) steuert und überwacht Systeme und deren Anwendungen, z.B. 
SINIX, BS2000, UNIX, MS-DOS, OS/2-Systeme. Zu den Standard-Funktionen ge- 
hören Ausfallüberwachung, Domänen-Konzept und automatische Ereignisüberwa- 
chung. 
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Die wachsende Anzahl vernetzter Systeme und ihre Kommunikation über LAN und 
WAN haben zu Entwicklungen geführt, die die Sicherheit in Systemen und Netz- 
werken betreffen. Gleich welche Sicherheitsmaßnahmen eingeführt sind, sie liegen 
in der Verantwortung der System- und Netzwerkverwalter. Für diese Aufgaben 
brauchen sie entsprechende Werkzeuge. Siemens Nixdorf und andere Unterneh- 
men, die sich mit offenen Systemen beschäftigen, arbeiten an der Entwicklung von 
Standards und Protokollen für die sichere Systemverwaltung. Die Entwicklung von 
Standards und Produkten für die Sicherheit ist im Abschnitt „Erweiterte Sicherheit- 
sfunktionen unter SINIX” auf Seite 191 beschrieben. Eine Implementierung von 
Software für Netzsicherheit, der Sicherheitdienst von DCE, ist in 
Abschnitt „Verteilte Verarbeitung: DCE als Lösungsmodell” auf Seite 132 beschrie- 
ben. 
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Überblick 


Moderne Firmen folgen dem Trend der Zeit und arbeiten heute nicht mehr nur mit 
großen Rechenzentren, sondern bevorzugen dezentrale Netzwerklösungen. Anwen- 
der wollen auf gemeinsame Ressourcen zugreifen, seien es Datenbanken oder Peri- 
pheriegeräte (wie Hochleistungs-Laserdrucker oder optische Laufwerke). Dies 
kann am besten durch die gemeinsam nutzbare Rechenleistung von PCs und Abtei- 
lungsrechnern erreicht werden. Dafür steht nun ein breites Spektrum von Anwen- 
dungen zur Verfügung, die alle den gleichen Lösungsansatz haben: verteilte Verar- 
beitung. Die umfassendste und effektivste Anwendung in diesem Bereich, mit den 
meisten Funktionen und Werkzeugen, ist DCE (Distributed Computing Environ- 
ment). 


Ziel der verteilten Verarbeitung ist es, allen Benutzern die in einem Netzwerk bereit 
gehaltenen Ressourcen verfügbar zu machen, um so eine leistungsfähige Arbeits- 
umgebung zu schaffen. Verteilte Verarbeitung ist deshalb vor allem für solche An- 
wender interessant, die schon heute über komplexe Rechnersysteme in einem hoch- 
entwickelten Netzverbund verfügen. In Kürze wird die verteilte Verarbeitung 
standardmäßig Teil der Datenverarbeitung im Geschäftsleben sein. 


Anbieter von Betriebssystemen, Netzwerken und unabhängige Softwarehäuser ha- 
ben in der Vergangenheit im Bereich der verteilten Verarbeitung eine breite Palette 
von Produkten angeboten. Diese Produkte ermöglichen bis zu einem gewissen Grad 
die Kommunikation zwischen Rechnern. Mit diesen Produkten kann man E-Mail 
verschicken, sich Drucker teilen, Dateien austauschen, sich an fernen Rechnern an- 
melden oder Speicherplatz auf Festplatten teilen. 


Heute suchen Kunden nach einer Lösung, die ihnen die Vorteile der integrierten und 
offenen Systeme bringt, damit alle schon vorhandenen vernetzten Systeme mitein- 
ander kommunizieren können, ob dies nurı Großrechner, Minicomputer, Work- 
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stations oder PCs sind. Eine umfassende Systemlösung mit verteilter Verarbeitung 
ist offensichtlich wünschenswert, um die Bedürfnisse eines Betriebs im Bereich der 
Informationssysteme zu erfüllen. 


Was Anwender nicht Fall wünschen, ist verteilte Verarbeitung, die nur auf einer be- 
stimmten Rechnerarchitektur eines einzigen Anbieters basiert. Gewünscht wird 
vielmehr echte, wirkungsvolle Zusammenarbeit. Gefragt ist verteilte Verarbeitung, 
die sich ohne weiteres in einen heterogenen Maschinenpark mit unterschiedlichen 
Architekturen, Betriebssystemen und Kommunikationsprotokollen einpassen läßt. 


Das oberste Ziel der verteilten Verarbeitung ist es, Ressourcen und Dienste netz- 
weit, also von jedem Rechner aus, in einer Firma nutzen zu können. Die beste Lö- 
sung für dieses Problem ist die Client-Server-Architektur. 
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Client-Server-Architektur 


Während man früher von einem Konzept ausging, das eine Anwendung als etwas 
Monolithisches ansah, geht man in der Client-Server-Architektur davon aus, daß 
Komponenten einer Anwendung auf Clients und Server verteilt werden können. Die 
Serverkomponenten stellen dabei Ressourcen allgemein zur Verfügung. Die Client- 
komponenten vermitteln lokal den Anwendungen die Dienstleistungen der Server. 


Theoretisch ist es möglich, daß die Serverkomponente einer Anwendung von einem 
einzigen Rechner aus alle Netzwerknutzer bedienen kann. Die Praxis sieht aller- 
dings meist so aus, daß ein Server auf mehreren Rechnern im Netz liegen kann und 
so durch die Verringerung der Leitungswege im Netz die Verfügbarkeit deutlich er- 
höht wird. Bekannteste Beispiele für diese Architektur sind die häufig eingesetzten 
Drucker-Server, File-Server oder Mail-Server. 


Die Clientkomponente einer Anwendung wird jeweils auf dem Rechner installiert, 
auf dem die betreffende Anwendung von Benutzern gebraucht wird. Die Client- 
komponente arbeitet als Schnittstelle zum Server, d.h. sie steuert sowohl den Daten- 
fluß im Netzwerk zwischen Anwender und Server als auch die Daten, die auf dem 
Bildschirm ausgegeben werden. Eine Ausnahme bildet X Window; hier steuert der 
Server die Bildschirmausgabe, während die Clients beliebige Anwendungen auf ei- 
nem beliebigen Rechner im Netz sein können, die dann auf diese Bildschirmsteue- 
rung zurückgreifen. 


Schon in der älteren Literatur findet man den Begriff Client-Server-Architektur. Da- 
mit ist Jedoch nur ein einfacher Verbund von Client-Rechnern und Server-Rechnern 
gemeint. In diesem Modell kommen nur dedizierte Client- oder Server-Systeme 
zum Einsatz, die entweder Träger von Client- oder Träger von Serverkomponenten 
sind. Dies ist beispielsweise in einem Netzverbund aus PC-Clients und SINIX-Ser- 
vern gegeben. In Systemen mit Client-Server-Anwendungen mit komplizierter In- 
frastruktur (z.B. DCE) unterscheidet man nicht strikt zwischen einem dedizierten 
Client- oder Server-Rechner; ein Rechner kann gleichzeitig Träger sowohl von 
Clientkomponenten als auch von Serverkomponenten sein. 


Im komplexen Client-Server-Modell ist die Rolle der Clients und Server relativ und 
dynamisch. Was darunter zu verstehen ist, soll an folgendem Beispiel erläutert wer- 
den: Auf einem Rechner befindet sich der Drucker-Server. Ein anderer Rechner ar- 
beitet als File-Server. Der erste Rechner ist damit jedoch zugleich auch Client, denn 
er greift auf Dateien des File-Servers zu. Daneben können Serverfunktionen auch 
verteilt werden. Das bedeutet z.B., daß der Druckauftrag eines Clients auf einem er- 
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sten Rechner an den Drucker-Server eines zweiten Rechners weitergegeben wird, 
während ein anderer Druckauftrag des ersten Rechners vom Drucker-Server eines 
dritten Rechners bedient wird. Ein Server kann mehrere Dienste zur Verfügung stel- 
len, so kann z.B. der Server einer Kundenkreditbank mehrere Dienstleitungen wie 
Kontostandsabfrage, Barabhebung, Einzahlung oder Überweisung anbieten. 


Die zentrale Aufgabe bei der Konzipierung von verteilten Anwendungen besteht 
darin, die Anwendungen so zu strukturieren, daß eine sinnvolle Aufgabenteilung im 
Netz erreicht wird. Dies erfordert die Festlegung von Funktionseinheiten, d.h. 
Client- und Serverkomponenten, und die optimale Verteilung von Anwendungs- 
funktionen, Diensten und Daten zwischen Client und Server. Dabei sind folgende 
Kriterien zu berücksichtigen: 


® Netztopologie 

® Verfügbarkeit von Systemdiensten 
® Schnittstellen 

® Kosten 


Eine weitere wichtige Aufgabe neben der Festlegung von Client- und Serverkom- 
ponenten ist die Steuerung der Zusammenarbeit zwischen diesen Komponenten. 
Diese kann einfacher Art sein (1:1 Beziehung zwischen Server und Client), kann 
aber auch komplexer sein (z.B Zugriff eines Clients auf mehrere Server während ei- 
ner Transaktion). Schließlich gehört dazu, daß die Client- und Serverkomponenten 
eine optimale Leistung durch die im Multitasking/Multiusing gegebenen Möglıich- 
keiten der Prozeßparallelisierung bzw. asynchronen Verarbeitung erreichen. 
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Dienste der verteilten Verarbeitung 


Die ersten Produkte im Bereich der verteilten Verarbeitung bieten für besondere 
Aufgaben optimale Lösungen. Im folgenden Abschnitt werden drei dieser Dienste 
der verteilten Verarbeitung beschrieben: NFS, LM/X und SPOOL. 


Das verteilte Dateisystem NFS 


Das Network File System (NFS) wurde ursprünglich von Sun Microsystems ent- 
wickelt, wurde aber bald auch von einer großen Zahl weiterer Softwarehäuser an- 
geboten, darunter auch von Siemens Nixdorf. Das Network File System von Sie- 
mens Nixdorf heißt Distributed File System (DFS). 


In einem späteren Abschnitt dieses Kapitels wird das DFS von DCE beschrieben 
(siehe Abschnitt „DCE-Komponenten” auf Seite 135). Dieses DFS verfügt über we- 
sentlich bessere Leistungsmerkmale als NFS und ist außerdem in DCE eingebun- 
den, hat also damit eine vollständige Laufzeitumgebung für Entwicklung und An- 
wendung von Programmen in verteilter Arbeitsumgebung. 


NFS, eine Technologie, die schon seit geraumer Zeit verfügbar ist, stellt alle Grund- 
funktionen für ein verteiltes Dateisystem zur Verfügung. Dieses Dateisystem kann 
innerhalb eines lokalen Netzverbundes verteilt sein und von allen NFS-Client-Sy- 
stemen innerhalb dieses Netzes erreicht werden. NFS erlaubt Anwendern, mittels 
Programmen auf Client-Rechnern via Netzwerk Lese- und Schreibzugriff auf Da- 
teien eines Server-Rechners. Der Zugriff auf eine ferne Datei geschieht transparent 
für das Client-Programm und den Anwender. Das heißt, die Dateioperationen für 
die lokalen und die fernen Dateisysteme sind identisch. Ein Programm, das auf dem 
Client-Rechner abläuft, bemerkt also nicht, ob Dateioperationen an einer lokalen 
oder an einer fernen Datei ausgeführt werden. Soll eine Dateioperation von einer lo- 
kalen auf eine ferne Datei umgelenkt werden, so ist dafür immer eine Operation des 
lokalen Betriebssystemkerns notwendig. 


Ein weiterer Aspekt des transparenten Zugriffs ist die Geschwindigkeit, mit der auf 
Daten innerhalb des Netzes zugegriffen werden kann. Der Zugriff auf Daten muß so 
schnell erfolgen, daß es nur einen kaum wahrnehmbaren Unterschied zwischen dem 
Zugriff auf eine NFS-Ressource und einem lokalen Plattenzugriff gibt. Es sollten 
80% des Datendurchsatzes einer lokalen Platte erreicht werden. Oft erzielt der Zu- 
griff über NFS auf einen dedizierten NFS-Server einen besseren Datendurchsatz, 
als dies mit einer langsameren lokalen Platte möglich ist. 
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NFS war ursprünglich nur auf UNIX-Systemen verfügbar. Aufgrund der besonde- 
ren Nutzbarkeit wurde es bald auf eine Vielzahl von Systemen portiert, vom Groß- 
rechner bis zum PC für die unterschiedlichsten Betriebssysteme. Siemens Nixdorf 
liefert DFS (NFS) für SINIX-Systeme, BS2000- Systeme (Server) und PCs 
(Clients). 


Integration von SINIX- und PC-Netzen mit LM/X 
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Ursprünglich waren PCs nur dazu gedacht, die für einen Arbeitsplatz typischen PC- 
Anwendungen, Laufwerke und Drucker bereitzustellen. Aufgrund der Möglichkei- 
ten, die PCs heute bieten (Rechnerleistung, Speicherkapazität, grafische Bedien- 
oberfläche, individuelle Einstellung der persönlichen Arbeitsumgebung, Verfügbar- 
keit usw.) sowie ihrer steigenden Verbreitung, ist es durchaus sinnvoll, PCs in 
bestehende IT-Lösungen der Unternehmen zu integrieren bzw. neue IT-Konzepte 
unter Einbeziehung von PCs zu realisieren. 


Grundsätzlich kann man zwischen drei Integrationsebenen unterscheiden, wobei 
die Grenzen zwischen diesen Ebenen fließend sind: 


® PCs können dazu verwendet werden, Terminals zu emulieren (z.B. X- 


Terminals) und ermöglichen damit den Zugriff auf die Ressourcen anderer 
Computer (z.B. einen Mehrplatzrechner oder einen Großrechner). 


PCs können an ein LAN angeschlossen werden und sich auf diese Weise 
Ressourcen wie Drucker oder zentral auf Platte gehaltene Daten teilen. 


PCs können als Plattform für Client-Server-Anwendungen genutzt werden, 
sobald ein Mehrplatzrechner in das LAN eingebunden wird. Dieser stellt dann 
anderen Rechnern Ressourcen, wie z.B. eine große Festplatte, zur Verfügung. 
Geht man darüber hinaus, stößt man in Bereiche, die den echten verteilten 
Systemen zuzurechnen sind. 


Mit Erscheinen der MS-DOS-Version 3.0 im Jahr 1984 wurde es möglich, PCs mit 
MS-DOS als Betriebssystem unter Verwendung des LAN-Managers (LM) in lokale 
Netzwerke (LAN) einzubinden. Der LAN-Manager bietet PCs transparenten Zu- 
griff auf netzweit zugängliche Drucker und Plattenressourcen sowie eine Schnitt- 


stelle (APD), welche die Kommunikation zwischen einzelnen Programmen ermög- 
licht. 
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Der LAN-Manager wurde von Microsoft als Netzwerkbetriebssystem für PC-LANs 
entwickelt, ist aber mittlerweile auch auf SINIX-Systemen unter der Bezeichnung 
LM/X verfügbar. Der LAN-Manager ist auf unterschiedlichen Transportsystemen 
ablauffähig, was für die Anwendungen aber immer transparent bleibt. Der LAN- 
Manager besteht aus einer Client-Komponente, die auf den Client-Systemen MS- 
DOS, MS-Windows und MS-Windows NT eingesetzt wird, und aus der auf dem 
SINIX-System installierten Server-Komponente (LM/X). 


Für die Realisierung verteilter Anwendungen unter dem LAN-Manager stehen die 
folgenden Dienste und Schnittstellen, im folgenden nach Umfang und Zugriffsrech- 
ten differenziert, zur Verfügung: 


gemeinsamer Zugriff auf Dateien (shared files) 

- gemeinsamer, transparenter Zugriff auf Dateien des Servers 

-  File- und Record-Locking 

gemeinsame Druckerbenutzung (shared print) 

- gemeinsame Ausgabe auf Drucker am Server 

- Spoolsystem für Pufferung und Druckausgabe 

Benutzung von asynchronen Geräten des Servers (shared device)) 
- gemeinsamer, sequentieller Zugriff 

- Unterstützung aller SINIX-SPOOL-Systeme 


Named Pipes des LAN-Managers zur Unterstützung der bidirektionalen 
Programm-Programm-Kommunikation zwischen Client- und Server- 
Programmen 


Mailslots zur Unterstützung der unidirektionalen Programm-Programm- 
Kommunikation zwischen Client- und Server-Programmen 
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SPOOL: Drucken in Systemen mit verteilter Verarbeitung 
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SPOOL von Siemens Nixdorf ist ein Druckservice für verteilte Systeme. SPOOL 
macht Drucken und Druckverwaltung konsequent einfach. Es werden verschiedene 
Dienste zur Verfügung gestellt, dazu gehören Verwaltung von Druckaufträgen, lei- 
stungsfähige Druckerverwaltung und umfassende Druckfunktionalität. 


Die wichtigsten Leistungsmerkmale des SPOOL-Systems sind: 


® Möglichkeit des Ausdrucks auf beliebigen angeschlossenen Druckern 


© Zentrale Druckerverwaltung 

® Auftragssteuerung (Scheduling) 

® Lstverteilung, Kontingentierung, Abrechnung (Accounting) 
® Arbeitsmöglichkeit auch ohne verteiltes Dateisystem 

® Unabhängigkeit von der jeweiligen Netztopologie 


SPOOL stellt drei Schnittstellen bereit: eine menügesteuerte Bedienoberfläche, 
Kommandos auf Shellebene sowie eine Schnittstelle für C-Programme. SPOOL ist 
objektorientiert zu bedienen, d.h., wenn mit SPOOL ein Auftrag bearbeitet werden 
soll, wird einer Aktion immer ein Objekt zugeordnet. Wenn man also einer beste- 
henden Konfiguration einen neuen Drucker hinzufügen will, führt man die Aktion 
„Gerät hinzufügen“ aus, wenn man einen Druckauftrag anstoßen will, führt man 
die Aktion „Druckauftrag ausführen“ aus. SPOOL unterstützt sieben verschiedene 
Aktionen, die auf 15 verschiedene Objekte angewandt werden können. Dieser ob- 
jektorientierte Ansatz ermöglicht eine äußerst benutzerfreundliche Bedienung und 
ist damit ein konsequenter Schritt in Richtung einfacher Handhabung. 


Die eigentliche SPOOL-Software besteht aus den fünf Grundkomponenten Client, 
Server, SPOOL-Systemverwaltung, Datenbankverwaltung sowie Dämon und kann 
im Netz auf verschiedene Rechner verteilt werden. Die einzelnen Teile kommuni- 
zieren über ein eigenes Protokoll, das auf Standardtransportsystemen beruht. 
SPOOL entspricht den X/Open-Standards für Systemaufrufe und Bibliotheken. 
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SPOOL unterstützt eine breite Palette von unterschiedlichen Druckern. Aber auch 
ein neuer Drucker kann durch Definition eines neuen PCL-Objekts (Printer Capa- 
bilities List) mit den entsprechenden Druckermerkmalen aufgenommen werden. 
Dies wird durch folgende Eigenschaften der PCL-Objekte gewährleistet: 


® Unterstützung der standardmäßigen Control-Zeichen 
® Übersetzung der Optionen eines Druckauftrags 

® Datenanalyse 

® Dialog mit dem Drucker 


SPOOL hat eine Client-Server-Architektur (mehr dazu im nächsten Abschnitt ‚‚Ver- 
teilte Verarbeitung: DCE als Lösungsmodell” auf Seite 132), arbeitet mit kooperie- 
renden Prozessen (siehe Abschnitt „Kooperative Datenverarbeitung” auf Seite 210) 
und basiert damit auf modernen Konzepten. Das SPOOL-System hat eine ähnliche 
Architektur wie Backup (siehe Abschnitt „Backup” auf Seite 104). SPOOL von Sie- 
mens Nixdorf ist auch unter dem Namen XPrint auf einer Reihe von Maschinen an- 
derer Hersteller verfügbar; dazu gehören z.B. die SPARC-Systeme von SUN, die 
ICL DRS-Systeme und die Rechner von Unisys. USL (UNIX System Laboratories) 
setzt SPOOL in abgewandelter Form als Technologie für das Druckermanagement 
des Distributed System Management Framework ein. 
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Verteilte Verarbeitung: DCE als Lösungsmodell 


132 


Im Jahr 1990 führte die Open Software Foundation (OSF) eine Ausschreibung 
durch, an der sich weltweit führende Hersteller beteiligten. Das Ziel dieser Aus- 
schreibung war es, eine umfassende Basis für die Entwicklung und den Betrieb von 
verteilten Anwendungen zu schaffen: Distributed Computing Environment (DCE). 
Siemens Nixdorf brachte in diesem Zusammenhang mehrere Komponenten ein. 
DCE wurde 1993 in kompletter Funktionalität und Qualität als Produkt freigegeben. 


OSF sieht DCE als eine Reihe von Diensten und Werkzeugen, die Entwicklung, 
Einsatz und Pflege von Anwendungen für verteilte Verarbeitung in einem heteroge- 
nen Netz unterstützen. DCE ist also eine Art Infrastruktur, die die Entwicklung und 
den Betrieb von Anwendungen in verteilter Arbeitsumgebung erst ermöglicht. 


OSF sieht DCE als eine Vereinigung der Vorteile von offenen Systemen und der ver- 
teilten Verarbeitung. Denn DCE ist der erste Versuch, das Konzept der verteilten 
Verarbeitung in heterogenen Netzen zu unterstützen und dabei herstellerunabhängig 
von der Hardwarearchitektur und dem Betriebssystem zu bleiben. Mittlerweile hat 
sich in der Literatur und bei Computerzeitschriften dafür der Begriff „offenes ver- 
teiltes System“ eingebürgert. DCE kann dazu benutzt werden, sowohl offene Syste- 
me als auch proprietäre Systeme in einem einzigen, offenen und verteilten System 
zu integrieren. 


Mit DCE wird keine grundlegend neue Funktionalität angeboten, denn alles, was 
DCE bietet, existiert schon in der ein oder anderen Form. Das Grundlegende und 
Bahnbrechende an DCE ist die Integration von hochentwickelten Funktionsmerk- 
malen zu einem neuen Ganzen, das es nun ermöglicht, neue Anwendungen für ver- 
teilte Systeme zu entwickeln, ohne daß dabei eine Abhängigkeit von der 
Verteilungstechnologie eines bestimmten Software-Hauses gegeben ist. Dies garan- 
tiert bestmögliche, offene Zusammenarbeit auch unterschiedlicher Systeme. 


DCE zielt vor allem auf solche Probleme ab, die bei der Entwicklung von Anwen- 
dungen für verteilte Systeme auftreten, wie z.B. eine komplexe Programmier- 
schnittstelle für die Kommunikation zwischen verteilten Komponenten, schlechte 
Vorhersagbarkeit des Verhaltens und Heterogenität der Programmteile. So blieb bis 
jetzt die Zahl der Anwendungen für verteilte Systeme beschränkt, da bislang nur die 
besten Entwickler der Anforderung gerecht werden konnten, den Anwendern die 
Vorteile einer verteilten Systemumgebung zu erschließen. DCE stellt nun die 
Grundlagen bereit, damit Entwickler ihre Programme mit den Leistungsmerkmalen 
versehen können, die ihren Vorstellungen und ihrem Können entsprechen. Hierbei 
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zeigt DCE seine zwei besonderen Stärken: Dies sind einerseits Remote Procedure 
Calls, die in der Form den bekannten Local Procedure Calls ähneln und die Zusam- 
menarbeit zwischen Client und Server steuern. Andererseits ist dies die transparente 
Behandlung der verschiedenen Darstellungsformen von Daten in unterschiedlichen 
Systemen. 


Verteilte Systeme sind nicht notwendigerweise auch offene Systeme. Ein verteiltes 
System kann z.B. auf ein Netzwerk beschränkt sein, das aus einem homogenen Ma- 
schinenpark besteht, also Rechner eines Herstellers, mit gemeinsamer Architektur 
oder dem gleichen Betriebssystem. Allgemein verbreitet sind heute jedoch Netz- 
werktypen, hinter denen ein heterogener Maschinenpark steht. Deshalb ist eine der 
wichtigsten Eigenschaften von DCE die Fähigkeit, auch in einer heterogenen Um- 
gebung ablauffähig zu sein. Genau hier ergänzen sich beide Konzepte, offenes Sy- 
stem auf der einen und verteilte Verarbeitung auf der anderen Seite. So ist es durch- 
aus vorstellbar, daß ein Computerhersteller eigens eine Anwendung entwickelt und 
vermarktet, um den Kunden verteilte Verarbeitung zu ermöglichen, aber nur auf den 
herstellerspezifischen Systemen. Oder aber der Computerhersteller entschließt sich 
dazu, einen Schritt weiter zu gehen und auch andere Computerhersteller und deren 
Systeme mit einzubeziehen, sofern diese die gleiche Architektur oder das gleiche 
Betriebssystem haben. UNIX System V Release 4 ist ein gutes Beispiel hierfür. 
DCE von OSF geht aber nochmals einen Schritt weiter, denn DCE ist sowohl unab- 
hängig vom jeweiligen Hersteller als auch vom zugrundeliegenden Betriebssystem. 
Jeder Computerhersteller kann von OSF eine Lizenz für den Sourcecode von DCE 
erwerben und DCE auf eigene Rechner portieren. Auf diese Weise entsteht eine Si- 
tuation, in der die Kunden ein wirkliches offenes System erwerben und Teilnehmer 
an weltweit verfügbaren, offenen, verteilten Netzwerken werden können. 


DCE kommt zwar ursprünglich aus der UNIX-Welt, aber Rechner mit VMS, 
BS2000, MVS, MS-Windows oder anderen proprietären Betriebssystemen werden 
in Kürze über DCE-Portierungen verfügen und damit in verteilten Umgebungen ar- 
beiten. DCE baut auf dem TCP/IP-Transportsystem auf, welches auf vielen unter- 
schiedlichen Computersystemen verbreitet ist. DCE schützt die Investitionen der 
Kunden in ihre Computersysteme, denn durch die hohe Verfügbarkeit wird es mög- 
lich, leicht mit anderen Systemen zusammmenzuarbeiten. 
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Vorteile von DCE 
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Das Prinzip der verteilten Verarbeitung setzt Unternehmen in die Lage, schon vor- 
handene Netzwerke, wie LAN oder WAN, optimal auszunutzen. Besonders treffend 
kommt dies im folgenden Satz zum Ausdruck: „Die eigentlich so unterschiedlichen 
Konzepte vom offenen System und von der verteilten Verarbeitung hängen doch 
eng zusammen. Beide Konzepte sind für ein dezentrales Rechnerkonzept in einem 
modernen Unternehmen unentbehrlich.“ (“The concepts of an open system and a 
distributed system are separate but strongly related. They are both important in imp- 
lementing decentralized processing in a contemporary organization.”) [Building An 
Open System, J. Slonim, A. Schonbach, M. Bauer, L. MacRae, and K. Thomas, Van 
Nostrand Reinhold Company, New York: 1987, S. 3.] 


Große, heterogene Netzwerke finden eine immer größere Verbreitung. So verfügt 
z.B. eine amerikanische Firma über ein firmeneigenes Netzwerk mit über 50 000 
Anschlußknoten. Verteilte Verarbeitung bietet die Möglichkeit, innerhalb eines 
Netzverbundes alle Ressourcen allgemein verfügbar zu machen. Das ist weit mehr, 
als nur Ressourcen zu teilen, denn aus diesem System wird ein einziger virtueller 
Computer, dessen Kapazitäten von jedem Knoten innerhalb des Netzes aus erreich- 
bar sind. Das eröffnet ungeahnte Möglichkeiten. 


Seit die Leistungsfähigkeit von Server-Rechnern, Workstations und PCs so stark ge- 
wachsen ist, existiert das Phänomen, daß diese Leistungsfähigkeit nicht mehr voll 
ausgenutzt werden kann. Durch das Client-Server-Konzept wird es jedoch möglich, 
diese brachliegenden Ressourcen wieder zu aktivieren. So ist z.B. vorstellbar, daß 
die Bearbeitung der Kundenkonten eines Geldinstituts, zuvor auf Großrechnern im 
nächtlichen Batch-Betrieb durchgeführt, nun auf Workstations verlagert wird: wenn 
die Angestellten abends nach Hause gehen, arbeiten deren Workstations im Netz- 
verbund die Aufträge ab. 


Durch verteilte Verarbeitung können auch spezielle Ressourcen in einem Netzwerk 
nutzbar gemacht werden, z.B. ein System zur professionellen Bildbearbeitung auf 
einem Netzrechner, das von jedem beliebigen Netzknoten aus angesprochen werden 
kann. Es ist naheliegend, daß ein besonders leistungsfähiger Supercomputer extrem 
rechenintensive Aufgaben für einen Client bearbeitet, oder daß ein leistungsstarker 
Datenbank-Server einer großen Zahl von Clients, die auf anderen Rechnern liegen, 
schnellen Zugriff auf eine gemeinsame Datenbank ermöglicht; dabei können die 
einzelnen Anwender selbstverständlich an ganz unterschiedlichen geographischen 
Punkten der Erde arbeiten. 
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Dies ist natürlich nur ein kleiner Ausschnitt der Anwendungen, die in verteilter Um- 
gebung arbeiten. DCE bietet dafür eine Infrastruktur, mit der entsprechende An- 
wendungen entwickelt werden können. Einige dieser Anwendungen werden Anpas- 
sungen von schon bestehenden Anwendungen an die Client-Server-Architektur 
sein. Daneben wird es völlig neue Anwendungen mit Client-Server-Architektur ge- 
ben, die dann die verteilte Verarbeitung optimal ausnutzen. 


DCE-Komponenten 


Directory Service 


Security Service Dr 


Time Service 


Abbildung 7-1: Die einzelnen DCE-Komponenten bilden eine integrierte Umgebung für Entwicklung und Betrieb 
von Client-Server-Anwendungen in verteilter Verarbeitung 
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RPC: Remote Procedure Call 


Einen zentralen Bestandteil von DCE bilden die sogenannten Remote Procedure 
Calls (RPC), frei zu übersetzen mit: Aufruf ferner Prozeduren. Diese Remote 
Procedure Calls steuern die Kommunikation zwischen Client- und Server-Kompo- 
nenten. Andere DCE-Komponenten, z.B. CDS, Security oder Time sind ebenfalls 
unter Zuhilfenahme von RPC geschrieben. Für Anwendungsprogrammentwickler 
ist es relativ einfach, Programme mit RPC zu schreiben, denn sie stellen nur eine 
Erweiterung der schon geläufigen Prozeduraufrufe für eine Netzumgebung dar. 


Eine aufrufende Prozedur und die aufgerufene, lokale Prozedur werden im gleichen 
Adreßraum (Prozeß) ausgeführt. Eine ferne Prozedur hat einen anderen Adreßraum 
(Prozeß) zur Verfügung, da sie auf einem anderen Rechner abläuft. Die RPCs erspa- 
ren es dem Anwendungsprogrammentwickler, sich um diese Dinge zu kümmern. 
Die bereitgestellten DCE-Dienste meistern alle schwierigen Aufgaben: sie finden 
den geeigneten fernen Rechner, bauen die Verbindungen auf, kontrollieren die 
Kommunikation zwischen Client und Server und verarbeiten auch unterschiedliche 
Datenformate der einzelnen Systeme. 


Bei der Entwicklung einer DCE-Anwendung ist darauf zu achten, daß streng zwi- 
schen der Server- und der Client-Komponente des Programms unterschieden wird. 
Deshalb müssen Schnittstellen zwischen Server und Client festgelegt werden, die in 
einer C-ähnlichen Sprache, der Interface Definition Language (IDL), geschrieben 
sind. 


Einer der wichtigsten Vorteile der RPCs in DCE ist die Verwendbarkeit der zugrun- 
deliegenden Semantik auch in unterschiedlichen Transportsystemen. So werden zur 
Zeit die verbindungslosen Dienste über UDP/IP und die verbindungsorientierten 
Dienste über TCP/IP unterstützt. Ein Programmentwickler braucht lediglich das ge- 
wünschte Transportsystem auszuwählen. 


Durch die zugrundeliegenden Threads (deutsch: Stränge; Unterprozesse) können 
mit RPC innerhalb eines Prozesses mehrere Aktivitäten parallel ablaufen. Ein 
Client kann mehrere parallele RPCs aussenden, die Server führen diese Aufrufe 
auch parallel aus. Diese Fähigkeit bringt große Leistungsvorteile bei der verteilten 
Verarbeitung, denn dadurch wird eine Anwendung hierarchisch in Aufgaben aufge- 
teilt, die dann wiederum auf verschiedenen Prozessoren parallel bearbeitet werden 
können. 
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Die RPCs sind auch eng in die Security- und Directory-Dienste von DCE eingebun- 
den, um sichere RPCs auf transparente Weise zu unterstützen. Die gewünschte Si- 
cherheitsstufe wird dabei in der Schnittstellenbeschreibung festgelegt. Der Di- 
rectory-Dienst macht es möglich, daß Clients automatisch den passenden Server 
finden können. 


Lokale Anwendung 


Hauptprogramm 


Prozedur A Prozedur B 


Verteilte Anwendung 


Server-System 


Client-System 


Server Framework 


Hauptprogramm 


Stub A 


Prozedur B 


Abbildung 7-2: RPCs erweitern Mechanismen, wie sie von Local Procedure Calls her bekannt sind, zur Unterstüt- 
zung der Client-Server-Kommunikation. 
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Threads 


Das ist natürlich nur ein Ausschnitt, denn ein Remote Procedure Call erfordert einen 
höheren Programmieraufwand als ein Local Procedure Call, weil das Hauptpro- 
gramm und die Prozedur nicht mehr Teil desselben Prozesses sind. Sowohl der 
Client-Prozeß mit dem Hauptprogramm als auch der Server-Prozeß mit der Proze- 
dur müssen verläßlich zusammenarbeiten und miteinander kommunizieren. Der 
Grad der Sicherheit ist dabei abhängig von der Art der Netzverbindung, die z.B. vor 
Hackern sicher bleiben soll. Beim eigentlichen Datenaustausch zwischen Client 
und Server kann man noch einen höheren Grad der Vertraulichkeit einbauen, z.B. 
durch Verschlüsselung der Daten. Dies alles zeigt, warum Remote Procedure Calls 
allein noch kein DCE ausmachen. 


In einem System mit verteilter Verarbeitung benötigt man Threads zur Kontrolle der 
Vorgänge innerhalb eines Prozesses. Normalerweise braucht man für einen DCE- 
Anwendungsserver pro aktiver Anfrage eines Clients auch jeweils einen Thread. 
Damit wird die Parallelverarbeitung verschiedener Aufgaben innerhalb eines Pro- 
zesses möglich. In UNIX erreicht man normalerweise eine ähnliche Funktionalität, 
indem man einen Prozeß vervielfältigt. Es ist allerdings weit weniger aufwendig, 
mit Threads zu arbeiten, als einen Prozeß zu vervielfältigen, zumal sich Threads 
auch wesentlich besser gemeinsame Daten teilen können. Normalerweise arbeitet 
nur das Betriebssystem mit Threads, DCE-Threads sind jedoch betriebssystemun- 
abhängig, alle weiteren DCE-Komponenten bedienen sich dieser Threads. 


Das Konzept der DCE-Threads basiert auf dem POSIX-Entwurf 1003.4a „Threads 
Extension for Portable Operating Systems“ (Threadserweiterung für POSIX). Die- 
ser Entwurf bildet auch die Grundlage für die Verwendung des Threads-Konzepts 
in UNIX, so daß schon existierende Anwendungen, die auf dem Konzept der DCE- 
Threads beruhen, angepaßt und unter einem UNIX mit Threads-Funktionalität 
rasch eingesetzt werden können. 


Ein Serverprozeß wird normalerweise nicht nur von einem einzigen Client ange- 
sprochen. Man könnte theoretisch alle RPCs streng der Reihe nach abarbeiten las- 
sen. Wenn nun aber die Abarbeitung eines RPCs mit Wartezeiten verbunden ist, 
dann werden währenddessen völlig unnötigerweise alle anderen Anforderungen 
auch zum Warten gezwungen. Ein Server wird deshalb normalerweise versuchen, 
eine Reihe von RPCs parallel abzuarbeiten, wozu DCE die Threads-Komponente 
bereitstellt. Threads sind sozusagen kleine Prozesse innerhalb eines Prozesses. Mit 
Threads können mehrere Aktivitäten innerhalb eines Prozesses parallel ablaufen. 
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Server-Prozeß 


Thread 1 Thread 2 


Abbildung 7-3: Server benutzen Threads zur simultanen Steuerung der Beziehungen zu den einzelnen Clients. 


Thread 3 Thread 4 


Client 


Auch Clients können auf Threads zugreifen, z.B. wenn ein Client schnell bestimmte 
Informationen von einigen Servern erhalten möchte. Ein konkretes Fallbeispiel: ein 
zentraler Client, Anwendung für eine Einzelhandelskette, fragt Daten von den Ser- 
vern, den einzelnen Läden der Kette, ab und erstellt aus diesen Daten dann einen 
Ergebnisbericht. Mit Hilfe der Threads kann ein Client weiterhin neue Anfragen ab- 
schicken, gleichzeitig auf die Antworten warten und daneben die eingehenden Da- 
ten ordnungsgemäß bearbeiten. 


Der Einsatz dieser Threads erfordert einen hohen Aufwand bei der Programmierung 
von Serverkomponenten, da es sich hier um eine Form der Parallelprogrammierung 
handelt. Es ist besonders darauf zu achten, daß Daten, die von mehreren Threads be- 
nutzt werden, auch besonders geschützt werden. Die Threads-Komponente enthält 
jedoch alle hierfür nötigen Sperr- und Synchronisationsmechanismen. 
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CDS: Cell Directory Service 
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Mit DCE verfolgt man das Konzept, viele Computersysteme zu einem einzigen vir- 
tuellen System zu vereinigen; deshalb ist es auch notwendig, bestimmte Namens- 
konventionen festzulegen, damit einzelne Objekte dieses Systems eindeutig identi- 
fizierbar bleiben. Wenn es nur einige wenige Dateiverzeichnisse gibt, z.B. /usr oder 
/bin, ist dies natürlich nicht problematisch. Wenn die Zahl der Dateiverzeichnisse 
oder anderer Ressourcen, wie z.B. Drucker, in die Hunderte oder gar Tausende geht, 
muß ein neues Konzept der Namensgebung eingesetzt werden. 


DCE bietet für diesen Bereich den Cell Directory Service (CDS). Eine Zelle ist eine 
beliebige administrative Einheit aus mehreren DCE-Rechnern. Häufig wird eine 
Zelle aus einem lokalen Netz (LAN) gebildet, was aber keine notwendige Voraus- 
setzung für DCE ist. Eine Zelle kann auch aus dem Zusammenschluß mehrerer 
LANs oder aus dem Zusammenschluß mehrerer LANs mit fernen Rechnern gebil- 
det werden. Ebenso kann eine Zelle aus einer einzigen Maschine bestehen, aus ei- 
nem Dutzend oder aus Tausenden. Das Zellenkonzept wurde in den CDS einge- 
führt, um Einheiten, wie die eben dargestellten, benennen zu können. Eine 
Minimalkonfiguration einer Zelle besteht aus Authentication-Server, Time-Server 
und CDS-Server. 


Dienstleistungs- 
Angebot 


Hilfedienste 


Abbildung 7-4: Der Directory Service ist mit den gelben Seiten eines Telefonbuchs vergleichbar. Server bieten ihre 
Dienste an, Clients nehmen diese in Anspruch. 
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Wenn DCE in großen, geographisch getrennten, verteilen Netzverbünden arbeitet, 
benötigt man zur Organisation und Strukturierung dieser riesigen Arbeitsumgebung 
sogenannte Zellen. Die Zellen haben natürliche Grenzen, innerhalb dieser Struktu- 
ren können Sicherheitsabfragen durchgeführt, Namen vergeben und Dateisysteme 
verwaltet werden. Die Zellengrenzen schränken nicht die Kommunikationsfähig- 
keit der einzelnen Rechner untereinander ein, die DCE-Architektur kann aber für 
bestimmte Operationen innerhalb dieser Grenzen optimiert werden. 


Der Directory-Service unterstützt das Auffinden der einzelnen Dienste im DCE- 
Netz. Sobald ein Server seinen Betrieb aufnimmt, meldet er sich beim Directory- 
Service an. Auf diese Weise ist der Directory-Service immer auf dem neusten Stand 
und kann seiner Aufgabe als Wegweiser im DCE-Netz nachkommen. Ein Client, 
der einen Dienst benötigt, macht seinerseits eine entsprechende Anfrage an den Di- 
rectory-Service. Ein und derselbe Dienst kann mehrfach im Netz angeboten werden, 
ein Client kann dann entweder zufällig einen passenden Dienst in Anspruch nehmen 
oder aber einen entsprechenden Dienst nach bestimmten Kriterien auswählen. 


Weitere wichtige Eigenschaften des Directory-Service sind hohe Verfügbarkeit 
durch parallele Datenhaltung, gute Leistung durch Schreiben der Daten in Puffer 
auf den einzelnen Knotensystemen, Eignung sowohl für kleine als auch für große 
Datenmengen durch hierarchische Strukturierung der Verzeichnisinformationen. 
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Synchronisation der Systemzeiten: Time-Service 
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DCE bietet mit dem Distributed Time Service (DTS) einen Dienst zur Zeitsynchro- 
nisation an. DTS verfügt über eine Schnittstelle zu einem externen Zeitgeber (z.B. 
das Signal eines Zeitzeichensenders). Synchrone Systemzeiten sind für die funktio- 
nierende Zusammenarbeit unbedingt notwendig, weil nur dann die Zeitmarken, die 
auf verschiedenen Rechnern erzeugt wurden, sinnvoll verglichen werden können 
und die Zeitbestimmung für bestimmte Ereignisse über Rechnergrenzen hinweg ex- 
akt ist. Die meisten verteilten Algorithmen, die z.B. von CDS, dem Sicherheits- 
dienst und DFS benutzt werden, funktionieren nur dann einwandfrei, wenn die 
Systemzeiten synchron laufen. 


Abbildung 7-5: Der Time-Service sorgt für die Synchronisierung der einzelnen Systemzeiten. 
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Sicherheit: Security-Service 


DCE bietet mit dem Security-Service Dienste an, die es ermöglichen, in verteilten 
Systemen auch über unsichere Verbindungen miteinander zu kommunizieren und 
dabei über ein hohes Maß an Sicherheit beim Zugriff auf Ressourcen zu verfügen. 
Der DCE-Security-Service überprüft drei wichtige Aspekte: 


® Identität 
® Autorisierung 
® Integrität der Kommunikation 


Über die Dienste des Directory-Service können sich zwei Partner (Client und Ser- 
ver) ausfindig machen. Es stellt sich nun für die Partner die Frage, ob sein Gegen- 
über wirklich der ist, für den er sich ausgibt. Der Server möchte natürlich wissen, 
wer seine Dienste in Anspruch nehmen möchte, damit später die erbrachten Lei- 
stungen abgerechnet werden können. Der Security-Service bietet dazu den Authen- 
tisierungs-Service an, vergleichbar einem verteilten „login“. Dieser Vorgang wird 
bisher mit Paßwörtern durchgeführt, aber an einer Integration von neuen Sicherheit- 
stechnologien (z.B. intelligenten Chipkarten) wird derzeit gearbeitet. Nach der Ab- 
frage kennt der Security-Service zuverlässig die Identität von Client und Server und 
tritt dann als Vermittler zwischen den Partnern auf. 


Ein weiterer Aspekt ist die Kontrolle des Zugangs und der Zugriffsrechte: wer darf 
was im DCE-Netz. Der Security-Server bietet durch Verwaltung der Zugriffsdaten 
auch hierfür geeignete Unterstützung: Über Access Control Lists (ACL) lassen 
sich, falls erforderlich, für jedes einzelne Objekt und jeden einzelnen Benutzer die 
Zugriffsrechte regeln. 


143 


7 Verteilte Verarbeitung 


144 


Sicherheits- 
Server 


Identitätsprüfun 


Autorisierungsprüfung 


Integritätsprüfun 
Client = _ 


Abbildung 7-6: Der Security Service überprüft Identität, Autorisierung und Integrität. 


Beim eigentlichen Datenaustausch werden verschiedene Ebenen der Integrität ga- 
rantiert (z.B. Schutz vor verfälschten Nachrichten) sowie Vertraulichkeit (z.B. Da- 
tenverschlüsselung). Naturgemäß verursacht ein höheres Sicherheitsniveau auch 
eine höhere Inanspruchnahme des Systems. Deshalb kann der Progammentwickler 
je nach Notwendigkeit das geeignete Sicherheitsniveau angeben. Das RPC-Lauf- 
zeitsystem kümmert sich dann in Zusammenarbeit mit dem Security-Service um die 
effektive Ver- und Entschlüsselung der Daten. Die Benutzung eines gesicherten 
RPCs unterscheidet sich also nicht von einem beliebigen anderen RPC. 
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GDS: Global Directory Service 


Der Global Directory Service (GDS), eine Entwicklung von Siemens Nixdorf, er- 
laubt die Verbindung zwischen den verschiedenen lokalen Zellen des globalen 
DCE-Netzes. GDS ist ein internationaler Verzeichnis-Dienst gemäß dem OSI bzw. 
X.500-Standard (X.500 ist die CCITT-Bezeichnung desselben Standards). Er wird 
von Anwendungen und Benutzern zum Speichern von Namen verwendet und stellt 
weitaus bessere Recherchemöglichkeiten als CDS bereit. 


DFS: Distributed File System 


Was die Zugriffsmöglichkeit auf ferne Dateien anbelangt, übertrifft das Distributed 
File System (DFS) das konventionelle NFS-Dateisystem bei weitem. DFS bietet 
eine einheitliche, systemunabhängige und hierarchische Namensgebung. Die ver- 
wendete Semantik entspricht voll dem POSIX-Standard, einschließlich der netz- 
weiten Sperrmechanismen. Teile der hierarchisch strukturierten Dateiverzeichnisse 
können mehrfach gehalten werden, um eine hohe Verfügbarkeit und eine gleichmä- 
Bige Auslastung zu erreichen. Um die Zugriffszeit auf Dateien zu verringern, wer- 
den Teile der Dateien in Puffern gehalten. DFS ist in besonderer Weise für die Ver- 
waltung von fernen Systemen ausgelegt und reduziert damit den 
Verwaltungsaufwand für Dateisysteme in großen Netzwerken. DFS ist voll kompa- 
tibel zu NFS und bietet einfache Migrationswege für alle NFS-Anwendungen. 


DFS baut innerhalb einer DCE-Zelle einen Dateibaum auf, bestehend wiederum aus 
Teilbäumen, die die einzelnen Systeme über DFS exportieren. Im Unterschied zu 
NFS sieht dieser Baum für alle beteiligten Systeme gleich aus. DFS implementiert 
auf seinen Dateien die volle Semantik eines lokalen Dateisystems, insbesondere 
gelten die gleichen Garantien für die Reihenfolge der Datenzugriffe und es gibt wir- 
kungsvolle Sperrmechanismen. 


Das verteilte Dateisystem (DFS) ist einerseits eine Komponente des OSF/DCE, es 
kann aber auch als Anwendung auf der Basis der anderen Dienste betrachtet wer- 
den. 
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DES ist voll kompatibel zum bestehenden UNIX-Dateisystem, bietet aber noch ein 
eigenes Dateisystem. Die Vorteile des neuen, lokalen Dateisystems sind geringe 
Ausfallzeiten nach einem Systemabsturz, die Möglichkeit der dynamischen Teil- 
baumverlagerung und Tabellen zur Zugangskontrolle. DFS und sein fortschrittli- 
ches Dateisystem bieten zusammen die interessante Möglichkeit, Teilbäume physi- 
kalisch zu verlagern, ohne daß sich für den Benutzer der Zugriffspfad ändert, ja 
sogar ohne daß die Benutzung des Teilbaums unterbrochen werden müßte. Flexibi- 
lität in der Konfigurierung, hohe Verfügbarkeit durch kurze Ausfallzeiten und ein 
Online-Backup-System sind Argumente, die DFS zu dem verteilten Dateisystem 
der Zukunft machen wird. 


Die DFS-Komponente wird zu einem späteren Zeitpunkt als Produkt zur Verfügung 
stehen, als die Grunddienste von DCE. Das ist zum einem in der Reihenfolge der 
Entwicklung begründet, denn DFS baut auf allen Diensten der Grundversorgung 
auf, aber zum anderen auch in der Komplexität und Innovationskraft dieser Techno- 
logie, sowie schließlich in den höheren Qualitätsanforderungen, die an einen so 
grundlegenden Dienst wie ein Dateisystem gestellt werden. 


Verfügbarkeit von DCE 


146 


DCE wird von vielen Herstellern gemeinsam zur Verfügung gestellt. Auf den Ce- 
BIT-Messen der Jahre 1991 und 1992 führte Siemens Nixdorf in Zusammenarbeit 
mit IBM, HP, Bull, Stratus und OSF eine Demonstration von DCE vor. Das Enga- 
gement dieser und anderer führender internationaler Anbieter stellt sicher, daß DCE 
sich als De-facto-Industriestandard durchsetzen wird. So verwendet derzeit X/Open 
viel Mühe darauf, die Spezifikation von DCE in das Common Applications Envi- 
ronment (X/Open CAE) zu übernehmen. Die ersten DCE-Dienste, die in das 
X/Open CAE aufgenommen werden, sind RPC und der Time-Service. Obwohl 
DCE ursprünglich in der UNIX-Welt entstand, wird es nicht darauf beschränkt blei- 
ben. Die Basisdienste von DCE lassen sich auch auf anderen Betriebssystemen be- 
reitstellen. Es gibt bereits entsprechende Ankündigungen sowohl aus der PC-Welt 
als auch aus dem Mainframe-Bereich. 
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DCE-Produkte von Siemens Nixdorf 


Als Hersteller der GDS-Komponenten war Siemens Nixdorf von Anfang an mit der 
Entwicklung von DCE befaßt. Siemens Nixdorf wird auch in Zukunft dafür sorgen, 
daß DCE auf unterschiedlichen Systemfamilien, wie SINIX, Windows oder 
BS2000, verfügbar ist. 


DCE (SINIX) 


DCE (SINIX) ist eine vollständige Implementierung von DCE in das SINIX-Be- 
triebssystem. Das Programm wurde von einem internationalen Entwicklerteam aus 
Deutschland und den USA bei Siemens Nixdorf entwickelt. OSF hat die Portierung 
von DCE auf SINIX (UNIX SVR4) als Referenzportierung für diese Betriebs- 
systembasis ausgewählt. Infolgedessen kam ein Kooperationsabkommen zwischen 
USL (UNIX System Laboratories), Vertreiber von UNIX SVR4, und Siemens Nix- 
dorf zustande, wonach Siemens Nixdorf im Rahmen dieses Vertrags die Portierung 
von DCE an USL zur Weitergabe an alle SVR4-Lizenznehmer liefert. Damit ist 
DCE von Siemens Nixdorf das standardmäßige DCE-Produkt auf allen SVR4- 
UNIX-Systemen. 


DCE (SINKX) ist in Form verschiedener Produkte Siemens Nixdorf verfügbar: 


Das Modul DCE Executive enthält das RPC-Laufzeitsystem, Threads und die Di- 
rectory- und Security-Clients. 


Das Modul DCE Developer enthält die Werkzeuge, die zur Entwicklung von DCE- 
Anwendungen gebraucht werden. 


Das Modul DCE Starter enthält alle Werkzeuge, die zur Erzeugung einer DCE- 
Zelle benötigt werden. Es stellt darüber hinaus die Komponenten für die Entwick- 
lung und die Ablaufumgebung von DCE-Anwendungen zur Verfügung. 


Der DCE Cell Directory Service ist der CDS-Server. Pro DCE-Zelle wird davon 
je ein Server benötigt. 


Der DCE Security Service ist der Sicherheits-Server. Darin eingeschlossen sind 
Verwaltung, Glaubwürdigkeitsprüfung und Ermächtigungsprüfung. 


Der DCE Crypto Service erweitert den Leistungsumfang von DCE-Executive. Im 
Zusammenwirken mit dem Security-Server können Daten verschlüsselt werden. 
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DCE (WIN) 
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DCE (WIN) läuft unter MS-Windows auf PCs und stellt die Verbindung zwischen 
PCs und DCE-Netzwerken her. DCE (WIN) ist eine MS-Windows 3.x Implemen- 
tierung des OSF/DCE. Dadurch kann auch ein PC als DCE-Client arbeiten (trusted 
peer). DCE (WIN) wird als Dynamic Link Library (DLL) zur Verfügung gestellt, 
weshalb Windows-Anwendungen vollen Zugriff auf die DCE-Anwendungspro- 
grammierschnittstelle (API) erhalten. 


Windows- Windows- 
Anwendung Anwendung 


‚ j Threads 


Eermtn een 


Socket DLL 


Transport (TCP/IP) 


Windows 3.X Kernel 


Abbildung 7-7: DCE (WIN) schafft die Voraussetzungen, um PCs als Clients in Arbeitsumgebungen mit verteilter 
Verarbeitung einzubinden. 
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Die Implementierung von DCE als DLL bringt als großen Vorteil eine Verringerung 
des Speicherplatzbedarfs, denn DLL-Routinen werden erst dann in den Arbeitsspei- 
cher geladen, wenn sie von einer Anwendung angefordert werden und können dann 
auch von anderen Anwendungen gemeinsam genutzt werden. Darüber hinaus benö- 
tigen DLLs innerhalb der einzelnen Anwendung keinen Adreßraum. Das DLL für 
DCE (WIN) stellt also DCE-Dienste zur Verfügung, ohne anderen PC-Anwendun- 
gen wertvollen Speicherplatz zu nehmen. DCE (WIN) bildet die Verbindung zwi- 
schen DCE und Standardanwendungen unter Windows. Damit können Standard- 
Windows-Anwendungen so konzipiert werden, daß PCs gleichwertige Funktionali- 
tät innerhalb eines DCE-Netzverbunds erhalten. Mit Hilfe der von Windows zur 
Verfügung gestellten Dienste können Daten direkt in Windows-Anwendungen ab- 
gebildet werden. Auf diese Weise können gängige Windows-Anwendungen für die 
Anwender einfach zu einer bequemen Schnittstelle in einem DCE-Netzwerk ge- 
macht werden. 


DCE (WIN) umfaßt verschiedene DCE-Komponenten. Dazu gehören der Secure- 
Core-DCE-Client mit Threads-Diensten, Client/Server-Funktionalität des RPC, 
Client-Funktionalität des Cell Directory Service, Security Service und Time Ser- 
vice. Es stehen darüber hinaus zwei Versionen mit jeweils unterschiedlichen Sicher- 
heitsstufen zur Verfügung: die Vollversion mit hoher Sicherheitsstufe verfügt über 
Verschlüsselungsmechanismen auf Anwendungsebene, die eingeschränkte Version 
unterstützt das DCE-Verschlüsselungsprotokoll. DCE (WIN) ist als Laufzeitversion 
und als Entwicklungswerkzeug (Application Developer’s Kit) verfügbar. 


Das Application Developer’s Kit (ADK) bietet Entwicklern die breite Palette der zu 
Windows kompatiblen Ressourcen und Werkzeuge, mit denen die volle Leistung 
von Windows-Anwendungen für DCE gewährleistet werden kann. Das Laufzeit- 
modul enthält die Laufzeitbibliotheken, die Installationsprogramme und die Benut- 
zerdokumentation. Es enthält auch die Programmteile, die auf einem PC installiert 
werden müssen, um die mit dem ADK entwickelten Programme ablauffähig zu ma- 
chen. Darüber hinaus bietet es weitere Programmkomponenten, wie z.B. ein DCE- 
Login-Programm, Laufzeitserver (RPC Dämon, CDS Clerk) und diverse Dienstpro- 
gramme (z.B. RPC und CDS-Kontrollprogramm, ACL Edit). Mit dem Laufzeitmo- 
dul kann eine eingeschränkte Version von DCE (WIN) erzeugt werden, die Ver- 
schlüsselungsoptionen auf DCE-Systemebene bietet. Soll eine Vollversion erzeugt 
werden, ist dazu das DCE (WIN) Crypt-Modul nötig. 
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DCE (BS2000) 
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DCE (BS2000) wird es ermöglichen, Anwendungsserver auf BS2000-Systemen zu 
installieren. BS2000-Systeme werden somit für Clients auf PCs und auf SINIX- 
Systemen nutzbar. Wegen des hohen Integrationsaufwands rechnen wir mit der Ver- 
fügbarkeit im zweiten Quartal 1994. 
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Überblick 


Typische Dialoganwendungen wie Buchungs-, Auskunfts-, Lagerhaltungs-, Be- 
stell- oder Produktionssteuerungssysteme haben die Eigenschaft gemeinsam, daß 
an einer großen Zahl von Terminals oder Workstations voneinander unabhängig 
Aufträge erteilt werden und mit aktuellen Daten aus zentralen Datenhaltungssyste- 
men, in der Regel Datenbanken, verarbeitet werden sollen. Die von diesen Anwen- 
dungen gemeinsam benötigten Leistungen und das Überwachen und Steuern der 
Ressourcen, wie z.B. Datenendgeräte mit Datenstationen und Druckern, gemeinsa- 
me Speicherbereiche im Verarbeitungsrechner, Prozesse, Programme usw., werden 
von einem Transaction-Processing-Monitor (TP-Monitor) übernommen, unter des- 
sen Steuerung die Anwendungen ablaufen. 


Ein TP-Monitor wird auch als Datenkommunikationssystem oder DC-System be- 
zeichnet. Zusammen mit Datenbanksystemen wie z.B. INFORMIX, ORACLE, 
oder UDS, ergibt ein TP-Monitor ein DB/DC-System. Solche Kombinationen wer- 
den in der Fachliteratur auch als OLTP-Systeme (On Line Transaction Processing) 
bezeichnet. Die Grundstruktur eines OLTP-Systems ist in Abbildung 8-1 darge- 
stellt. 


Unter einer Transaktion versteht man eine Folge von logisch verknüpften Arbeits- 
schritten, die entweder vollständig oder überhaupt nicht ausgeführt wird. Ein einfa- 
ches Beispiel ist die Überweisung eines Geldbetrags von einem Konto auf ein an- 
deres. Indem die Abbuchung vom einen Konto und die Überweisung auf ein 
anderes Konto zu einer einzigen Transaktion zusammengefaßt werden, verhindert 
man, daß nur ein Arbeitsschritt vollendet und ein anderer ausgelassen wird. Denn 
sonst könnte es geschehen, daß zwar Abbuchungen von einem Konto vorgenom- 
men werden, die dazugehörigen Überweisungen auf das andere Konto jedoch un- 
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terbleiben. Tritt der Fall ein, daß eine Transaktion nicht erfolgreich beendet werden 
konnte, werden automatisch alle an dieser Transaktion beteiligten Daten in den ur- 
sprünglichen Zustand zurückversetzt. 


Dialoganwendung 
Datenbank 


Anwender- 


TP-Monitor 


Betriebssystem 


Kommunikations-Netz 


Endbenutzer der 
Dialoganwendung 


Abbildung 8-1: Grundstruktur eines OLTP-Systems. 
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OLTP mit UTM (SINIX) 


OLTP auf SINIX-Systemen wird schon seit Jahren erfolgreich durchgeführt und da- 
bei in steigendem Umfang im unterbrechungsfreien 24-Stunden-Betrieb. Dadurch 
wird jeweils einer großen Zahl von Anwendern die gleichzeitige Benutzung ermög- 
licht. Siemens Nixdorf kann diesbezüglich auf einen reichhaltigen Erfahrungs- 
schatz aus der Mainframe-Welt zurückgreifen. Die Produkte, die für die Großrech- 
ner im kommerziellen Bereich entwickelt wurden, sichern einen enormen 
Wissensvorsprung bei der Anpassung von SINIX an Programme für den kommer- 
ziellen Großeinsatz. 


Ein Beispiel dafür ist die erfolgreiche Portierung von UTM, dem Transaktionsmo- 
nitor von Siemens Nixdorf aus der Mainframe-Welt auf UNIX-basierte Systeme im 
Jahr 1988. Mit mehr als 700 Installationen (Stand: Sommer 1992), ist UTM (SINIX) 
der am häufigsten eingesetzte Transaktionsmonitor auf UNIX-Systemen in Europa. 


OLTP-Systeme benötigen konsistente Daten und müssen gegenüber allen äußeren 
Störungen unempfindlich sein. Diese grundlegenden Anforderungen an die Trans- 
aktionsverarbeitung werden auf SINIX-Systemen mit einem Datenbanksystem 
(z.B. INFORMIX) und dem Transaktionsmonitor UTM erfüllt. Sie kommunizieren 
untereinander über die von X/Open als Standard festgelegte XA-Schnittstelle. 


SINIX wird häufig zusammen mit anderen Systemen im Netzverbund eingesetzt, so 
z.B. mit anderen SINIX-Systemen, mit Systemen aus der BS2000-Welt, der MS- 
DOS-Welt und anderen Systemen. Voraussetzung für eine umfassende Lösung für 
den Anwender ist, daß OLTP-Anwendungen und Daten im Netz verteilt gehalten 
werden können. Dabei ist die räumliche Verteilung für den Anwender nicht sichtbar, 
genausowenig wie erkennbar wird, an welchem Ort und von welchem System eine 
Transaktion durchgeführt wird. Das Netzwerk erscheint für den Benutzer als eine 
logische Einheit. Obwohl es sich dabei um technisch höchst komplexe und räumlich 
verteilte Systeme handelt, garantieren UTM und INFORMIX stets den reibungslo- 
sen Ablauf der Transaktionen sowie konsistente Datenhaltung. 


Siemens Nixdorf ist mittlerweile ein führender Anbieter von verteilten Transak- 
tionssystemen und Datenbanksystemen. Die vielfältigen Möglichkeiten der Konfi- 
guration verteilter Transaktions- und Datenbankverarbeitung mit UTM und 
INFORMIX stellen allen Kunden eine jeder Situation angepaßte Lösung zur Verfü- 


gung. 
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Anforderungen an einen Transaktionsmonitor 


Ein Transaktionsmonitor muß den folgenden Anforderungen genügen: 


® der Benutzerdialog wird von der jeweiligen Anwendung gesteuert 


® sehr viele Benutzer müssen gleichzeitig daran arbeiten können 


® die Daten einer derartigen Anwendung müssen immer konsistent sein 


die Anwendung muß unempfindlich gegenüber Störungen von außen sein; dies 
bedeutet im einzelnen, 


- daß ein Verbindungsverlust keinen Einfluß auf die Gesamtanwendung hat; 
ein vom Ausfall betroffener Benutzer kann seine Tätigkeit definiert fortset- 
zen. 


- daß der Ausfall einer Gesamtanwendung nur zu einer temporären Betriebs- 
unterbrechung führt, bis ein automatischer Wiederanlauf durchgeführt wer- 
den kann. 


- daß die Wirkung von Fehlern in Anwendungsprogrammen lokal bleibt. 
- daß eine Anwendung vor unberechtigten Zugriffen geschützt sein muß. 


Der Transaktionsmonitor UTM (SINIX) erfüllt oben genannte Anforderungen und 
stellt darüber hinaus weitere Funktionen zur Verfügung, so z.B. den Wiederanlauf 
von kompletten Anwendungen, die Synchronisation von lokalen Datenhaltungssy- 
stemen, die Kopplung von Anwendungen im Rechnerverbund, die Verwaltung von 
Verbindungen und die Nachrichtensteuerung bei lokalen Anwendungen und ım 
Rechnerverbund, das Konfigurieren der Hard- und Softwareumgebung und schließ- 
lich die Administration des gesamten Transaktionssystems. 


Benutzerschnittstelle 
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Die UTM-Programmschnittstelle erfüllt die einzige existierende Norm, nämlich die 
deutsche Norm DIN 66265 KDCS (Kompatible Datencommunikations-Schnittstel- 
le), ergänzt durch wichtige zusätzliche Aufrufe. 


Diese Schnittstellendefinition bestimmt im wesentlichen die Struktur der Teilpro- 
gramme, aus denen dann eine Anwendung gebildet wird. Die folgenden Begriffe 
sind hier von Bedeutung: 
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Dialogschritt 


Ein Dialogschritt beginnt mit einer Dialognachricht und endet mit der Antwort der 
Anwendung. Eine Transaktion besteht entweder aus einem oder aus mehreren Dia- 
logschritten. 


Vorgang 


Ein Vorgang ist die Abarbeitung eines in sich geschlossenen Auftrags durch eine 
Anwendung, bei der ein oder mehrere Teilprogramme durchlaufen werden. 


Teilprogramm 


Ein Teilprogramm ist ein selbständig übersetzbarer Teil des gesamten 
Anwendungsprogramms, der normalerweise einen Dialogschritt bearbeitet. Ein 
Teilprogramm wird durch seinen Transaktionscode (TAC), eine logische Bezeich- 
nung für das Programm, gekennzeichnet. 


Transaktion 


Das Raster der Sicherungspunkte innerhalb eines Vorgangs bestimmt die UTM- 
Transaktionen in diesem Vorgang. 


Sicherungspunkt 


Ein Sicherungspunkt beschreibt einen konsistenten Zustand aller Daten eines Vor- 
gangs und ist zugleich Rücksetzpunkt bei Fehlern und Aufsetzpunkt bei einem Wie- 
deranlauf nach einem Systemausfall. Am Ende eines Vorgangs wird immer ein Si- 
cherungspunkt gesetzt, weitere Sicherungspunkte innerhalb eines Vorgangs sind 
möglich. 


Dialogschritt und Teilprogrammlauf 


Aus Sicht der Anwendung beginnt ein Dialogschritt mit dem Empfang einer Nach- 
richt von der Datenstation (Client) und endet mit der Ausgabe der Antwort. Jeder 
Dialogschritt wird in mindestens einem Teilprogrammlauf bearbeitet. Das heißt, bei 
Eintreffen einer Nachricht wird ein Teilprogramm gestartet. Sobald das Teilpro- 
gramm beendet ist, wird die Antwort an die Station zurückgeschickt oder ein wei- 
teres Teilprogramm aufgerufen. 
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Transaktion und Vorgang 
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Eine der wichtigsten Aufgaben von UTM (SINIX) ist es, Benutzerdaten vor Störun- 
gen zu schützen. Richtet ein Benutzer einen Auftrag an eine Anwendung, sind bei 
Update-Vorgängen Modifikationen am zentralen Datenbestand notwendig. Diese 
Änderungen werden nicht gleichzeitig, sondern zeitlich versetzt durchgeführt. Tritt 
dabei ein Verbindungsverlust oder eine andere Störung auf, ist ohne TP-Monitor die 
Konsistenz der Benutzerdaten nicht mehr gewährleistet. 


Um dies zu verhindern, werden in UTM (SINIX) logisch zusammengehörige Auf- 
gaben zu Transaktionen zusammengefaßt. Alle innerhalb einer Transaktion stattfin- 
denden Änderungen der Daten werden gemäß der „Alles-oder-Nichts“-Regel ent- 
weder vollständig oder gar nicht ausgeführt. Die Transaktion ist in diesem Sinn eine 
unteilbare Verarbeitungseinheit. Da die Wirkung einer Transaktion auch nach einer 
abnormalen Beendigung erhalten bleiben muß, wird sie bei Transaktionsende gesi- 
chert. Das Transaktionsende heißt daher auch Sicherungspunkt. Die Aktionen einer 
nicht erfolgreich abgeschlossenen Transaktion werden, einschließlich der DB- 
Transaktionen, durch UTM (SINIX) zurückgesetzt. Insgesamt ist eine Transaktion 
durch folgende Eigenschaften gekennzeichnet, die unter dem Akronym ACID (Ato- 
micity, Consistency, Isolation, Duration) zusammengefaßt werden: 


Unteilbarkeit (atomicity) 

Die von einer Transaktion betroffenen Änderungen der Anwenderdaten werden ent- 
weder vollständig oder gar nicht ausgeführt. 

Konsistenz (consistency) 


Die Anwenderdaten sind jederzeit in einem konsistenten Zustand. 


Isolierung (isolation) 

Die Änderung von Daten, die in einer Transaktion durchgeführt wird, wird erst bei 
Transaktionsende für andere Benutzer sichtbar. 

Dauerhaftigkeit (duration) 


Ist eine Transaktion abgeschlossen, so ist ihre Wirkung dauerhaft. 
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Zurücksetzen einer Transaktion und Koordination mit Datenbank-Transaktionen 


Es gibt verschiedene Gründe, warum eine Transaktion zurückgesetzt werden muß, 
z.B. durch Anforderungen aus einem Teilprogramm, wegen vorzeitiger Beendigung 
der Anwendung, nach Verbindungsverlust, als Folge von Programmfehlern oder aus 
Systemgründen. Wird eine Transaktion zurückgesetzt, werden Speicherbereiche im 
Verarbeitungsrechner auf den Stand zurückgesetzt, den sie zu Beginn der Transak- 
tion hatten. Globale Speicherbereiche werden auf den Stand gebracht, den sie un- 
mittelbar vor dem ersten Zugriff in der Transaktion hatten. 


Die Daten eines mit UTM(SINIX) gekoppelten Datenbanksystems zählen ebenfalls 
zu den Anwenderdaten und unterliegen deshalb dem Transaktionsprinzip. Um die 
Transaktion als unteilbare Einheit zu erhalten, ist eine Koordination zwischen dem 
Transaktionsmonitor und dem Datenbanksystem notwendig. Soll eine Datenbank- 
Transaktion durch einen Aufruf im Teilprogramm beendet werden, wird die Been- 
digung im Datenbanksystem verzögert, bis auch die UTM-Transaktion beendet 
wird. Auch im Fall des Wiederanlaufs einer Anwendung findet eine Koordination 
mit dem Datenbanksystem statt. 


Wiederanlauf eines Vorgangs und einer Anwendung 


Wird ein aus mehreren Transaktionen bestehender Dialog unterbrochen, kann dieser 
Vorgang fortgesetzt werden. Befindet sich der Vorgang zum Zeitpunkt der Unterbre- 
chung nicht auf einem Sicherungspunkt, sondern innerhalb einer Transaktion, wird 
die Transaktion zurückgesetzt und der Vorgang am zuletzt erreichten Sicherungs- 
punkt fortgesetzt. Wurde eine Anwendung abnormal beendet, führt UTM (SINIX) 
automatisch den Wiederanlauf einer Anwendung durch. Die Daten der Anwendung 
werden auf den zuletzt erreichten konsistenten Zustand gesetzt. 


Anwendungen 


In einem Rechner können unter der Kontrolle von UTM (SINIX) mehrere vonein- 
ander unabhängige Anwendungen existieren. Jede dieser Anwendungen wird ge- 
sondert generiert und administriert. Der Betrieb kann somit unterschiedliche Auf- 
gaben, wie z.B. Lagerhaltung, Personalwesen, usw. in vollständig getrennten 
Anwendungen realisieren. Jeder Benutzer meldet sich bei der gewünschten Anwen- 
dung an und arbeitet ab diesem Zeitpunkt ausschließlich mit dieser Anwendung. 
Dabei ist es für die Anwendung ohne Bedeutung, wieviele Benutzer gleichzeitig mit 
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dieser Anwendung arbeiten. Datenstationen und Anwendungen im gleichen oder ei- 
nem anderen Rechner können logische Verbindungen aufbauen und Aufträge ab- 
senden. Eine Anwendung kann auch von sich aus Verbindungen zu anderen Kom- 
munikationspartnern im Netz einrichten und Nachrichten verschicken. 


Für jede Datenstation, die mit der UTM-Anwendung arbeitet, existiert ein eigener 
Dialogprozeß, der Dialogterminalprozeß (DTP) genannt wird. Er wird entweder 
durch expliziten Aufruf über die Shell oder automatisch nach erfolgreicher Anmel- 
dung des Datenstationsbenutzers an das SINIX-System gestartet. Für Ausgaben an 
Drucker werden spezielle Druckprozesse verwendet, die für jeden angeschlossenen 
Drucker eingerichtet werden. 


Die Netzanbindung der Anwendung erfolgt über getrennte Netzprozesse, die so- 
wohl den Verbindungsauf- bzw. -abbau, als auch den Datenaustausch zwischen den 
beteiligten Partnern abwickeln. Pro Verbindung wird ein eigener Prozeß verwendet, 
der bis zum Abbau dieser Verbindung existiert. 


Eine UTM-Anwendung wird durch Generierung mit Hilfe eines Dienstprogramms 
erstellt. Hierbei wird auch die von einer Anwendung benötigte Konfiguration fest- 
gelegt. Sie enthält u.a. folgende Informationen: 


® Transaktionscodes und deren Eigenschaften, 

® Anwendungsteilprogramme und deren Eigenschaften, 

® Datenendgeräte (Drucker und Terminals) und deren Verwendungsart, 
® Benutzernamen und deren Berechtigung, 

® verteilte Anwendungen und deren Eigenschaften. 


Gesteuert über weitere Parameter wird ein ablauffähiges Anwendungsprogramm er- 
zeugt, das neben den Anschlußroutinen an UTM (SINIX) die Anwendungsteilpro- 
gramme enthält. Dieses Gesamtprogramm wird mittels einer SINIX-Startprozedur 
als Hintergrundprozeß (der sogenannte Mainprozeß) gestartet. Danach werden von 
diesem Mainprozeß so viele Workprozesse aktiviert, wie in den Startparametern 
festgelegt wurde. 
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Verteilte Transaktionsverarbeitung mit UTM 


Die verteilte Transaktionsverarbeitung ist bereits seit der ersten Freigabe im Jahr 
1988 integraler Bestandteil von UTM (SINIX). Mit dieser Funktionskomponente 
wird die rechnerübergreifende Transaktionsverarbeitung ermöglicht. Neben Daten- 
stationen werden dafür auch ferne UTM-Anwendungen als Dialogpartner zugelas- 
sen, um mit Hilfe von Dialognachrichten Unteraufträge starten und Ergebnisse 
empfangen zu können. 


Da Unteraufträge durch entfernte Anwendungen in Form von Transaktionen abge- 
wickelt werden, liegen bei der verteilten Transaktionsverarbeitung ebenso wie bei 
einer DB/DC-Transaktion geschachtelte Transaktionen mit der Notwendigkeit der 
Synchronisierung vor. Der Unterschied besteht nur darin, daß Auftrag und Ergebnis 
als Dialognachrichten übermittelt werden und zur Synchronisation geeignete Kom- 
munikationsprotokolle (das sogenannte Two-Phase-Commit-Protokoll) verwendet 
werden. 


Die verteilte Transaktionsverarbeitung bietet auch die Möglichkeit, zwischen zwei 
UTM-Anwendungen parallele Verbindungen aufzubauen und mehrere Aufträge 
(auch Dialogaufträge) gleichzeitig abwickeln zu können. 


Eine UTM-Anwendung kann über verteilte Transaktionsverarbeitung mit einer 
Partneranwendung entweder synchron kommunizieren, d.h. eine Anwendung sen- 
det einen Dialogauftrag (Nachricht) an den Partner und wartet auf die Antwort, oder 
aber die Kommunikation erfolgt asynchron, also ohne direkte Antwort. 


Die verteilte Transaktionsverarbeitung in UTM (SINIX) ermöglicht die Transak- 
tionsverarbeitung von UTM-Anwendungen auch im Netzverbund von SINIX- und 
BS2000-Systemen. Wegen der Verwendung von Protokollen gemäß LU6.1 (IBM 
SNA) zur Kommunikationssteuerung ist eine gesicherte Verarbeitung zwischen den 
Transaktionssystemen UTM (SINIX) und CICS bzw. IMS von IBM möglich. Der- 
zeit in Entwicklung befindet sich die Implementierung von OSI-TP-Protokollen. 
Mit Hilfe dieser inzwischen unter ISO 10026 weltweit gültigen Norm wird eine 
Transaktionsverarbeitung mit Systemen aller Partner möglich, die diesen Standard 
ebenfalls realisiert haben. 
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Die derzeit verfügbaren bzw. in Vorbereitung befindlichen Kopplungsmöglichkei- 
ten über UTM (SINIX) sind in Abbildung 8-2 dargestellt. 


UTM(BS2000) NA 
UTM (SINIX) 


Fremd- 
system 


OSI-TP 
Nutzer 


Transdata-Netz mit 
NEA- oder ISO-Transportsystem 


Gateway mit Gateway mit 
TRANSDATA/SNA OSI-TP/LU6.2 
Umsetzung Umsetzung 


IMS 


CICS IMS 
MVS/DOS-VSE MVS/DOS-VSE MVS 


MVS 


OS/400 


Abbildung 8-2: UTM in einer heterogenen Netzwerkumgebung. 
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Die Client-Server-Architektur mit UPIC und UTM (SINIX) 


Ein wichtiges Kriterium für die erfolgreiche Handhabung der Schnittstelle zwi- 
schen Mensch und Maschine ist die anwendungsfreundliche Strukturierung der Be- 
dienoberfläche (Präsentationsschicht). Hierfür werden immer mehr die Möglichkei- 
ten von Produkten wie OSF/Motif und MS-Windows aus der SINIX- und der MS- 
DOS-Welt eingesetzt. Da die Bildschirmgestaltung eigentlich nicht Aufgabe eines 
Transaktionsmonitors wie UTM (SINIX) ist, wird die Bildschirmsteuerung zuneh- 
mend aus den bisherigen UTM-Anwendungsprogrammen in sogenannte Clients 
ausgelagert. Die eigentliche Verarbeitungsleistung wird als Server in den jeweiligen 
UTM-Anwendungen erbracht. 


UTM(SINIX) 


PC-Mecthanismus 


BS2000 | 


Abbildung 8-3: Client-Server-Kommunikation mit UPIC und UTM (SINIX). 
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Das Client-Server-Konzept hat zum Ziel, den Nutzern eines Rechennetzes die Res- 
sourcen des gesamten Verbundes (also Daten, Programme und Geräte) verfügbar zu 
machen. Ein Client-Server-Konzept ist immer dann sinnvoll einzusetzen, wenn vie- 
le Anforderer (Clients) vorhanden sind, die dieselben Dienstleistungen (Server) be- 
nötigen. Hierzu wurde das Produkt UPIC entwickelt, das eine Programmschnittstel- 
le gemäß der X/Open-Spezifikation CPI-C (Common Programming Interface for 
Communication) darstellt. Es ermöglicht die Kopplung von UPIC-Anwendungen 
mit UTM-Anwendungen, wie z.B. den Anschluß von grafischen Oberflächensyste- 
men. UPIC wurde auf alle in Betracht kommenden Systemlinien portiert und ist 
auch für MS-Windows und BS2000 verfügbar. Das prinzipielle Zusammenwirken 
von UPIC-Clients mit UTM-Servern in SINIX und BS2000 ist in Abbildung 8-3 
dargestellt. 


Im Vordergrund der Entwicklungen zur Ergänzung des Funktionsumfangs von 
UTM (SINIX) steht die Unterstützung neuer Standards in Bezug auf Kommunika- 
tionsprotokolle und Benutzerschnittstellen. Die Implementierung des OSI-TP-Stan- 
dards ist gegenwärtig in Arbeit und wird mit der nächsten Version von UTM 
(SINIX) freigegeben. Über einen derzeit in Entwicklung befindlichen Protokollum- 
setzer OSI-TP/LU6.2 kann dann auch mit Anwendungen kommuniziert werden, die 
das LU6.2-Protokoll von IBM anwenden. 


Um die weitere Verbreitung von UTM (SINIX) in der Welt der offenen Systeme zu 
fördern, ist es notwendig, die Benutzerschnittstelle KDCS (deutscher Standard) 
durch international festgelegte Schnittstellen zu erweitern. Dazu werden in erster 
Linie die Festlegungen von X/Open Verwendung finden. Als erster Schritt wurde 
bereits die gesicherte Kommunikation mit Datenbanksystemen (Ressourcen- 
manager) über die Systemschnittstelle XA realisiert, und mit INFORMIX und einer 
Pilotversion von ORACLE V7 erfolgreich getestet. Nach Verabschiedung weiterer 
Standards gemäß des X/Open-Referenzmodells für Transaktionsverarbeitung sollen 
diese ebenfalls von UTM (SINIX) unterstützt werden. 
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Datenbanksysteme 


INFORMIX 


INFORMIX steht für eine weitverzweigte Familie von Datenbankprodukten, die für 
eine breite Palette von Rechnerarchitekturen, einschließlich der Rechner von Sie- 
mens Nixdorf, verfügbar ist. Neben dem eigentlichen DBMS (Database Manage- 
ment System) umfaßt die INFORMIX-Produktfamilie auch das ganze Spektrum 
moderner Datenbank werkzeuge und -schnittstellen sowie Komponenten zur verteil- 
ten Datenbankverarbeitung nach dem neusten Stand der Entwicklung. 


INFORMIX ist das im UNIX-Markt am weitesten verbreitete Datenbankprodukt. 
Mit einer Durchdringung des SINIX-Maschinenparks von etwa 50% beweist das 
Produkt seine hervorragende Eignung und Einsatzfähigkeit. Nach dem Erwerb der 
Sourcelizenz für INFORMIX-Produkte hat Siemens Nixdorf ein Team von Exper- 
ten aufgebaut, das die Portierung auf Siemens-Nixdorf-Systeme durchführt und 
Kunden bei Problemfällen sachkundig unterstützt. 


Aufgrund dieser strategischen Partnerschaft zwischen Siemens Nixdorf und 
INFORMIX Software, Inc. konnten einige gemeinsame Entwicklungsvorhaben er- 
folgreich abgeschlossen werden. Das hat zu einer stetigen Kompetenzsteigerung bei 
Siemens Nixdorf auf diesem Gebiet geführt. Dies wiederum stellt eine gute Grund- 
lage für die Abstimmung und Realisierung weiterer gemeinsamer Entwicklungszie- 
le dar. 


Im folgenden werden einige Produkte aus der INFORMIX-Familie kurz vorgestellt. 


INFORMIX-OnlLline 


INFORMIX-Online ist ein leistungsstarker, SQL-basierter relationaler Datenbank- 
server für OLTP, mit hoher Verfügbarkeit, hoher Verarbeitungsleistung unter Ge- 
währleistung der Datenintegrität sowie Multi-Media-Eigenschaften unter Einhal- 
tung des SQL-Standards (ANSI Level 2, 1989). 


INFORMIX-SE 


INFORMIX-SE ist ein einfach zu nutzendes SQL-basiertes relationales Datenbank- 
managementsystem, das für den Einsatz in kleinen und mittleren Anwendungen ge- 
dacht ist und ohne Datenbankadministrator betrieben werden kann. 
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INFORMIX-TP/XA 


C-ISAM 


INFORMIX-TP/XA verbindet INFORMIX-Online mit Transaktionsmanagern auf 
Basis der von X/Open standardisierten XA-Schnittstelle. Hiermit können globale 
Transaktionen auch über mehrere heterogene Computer- und Datenbanksysteme 
hinweg für eine Vielzahl von parallelen Nutzern koordiniert werden. 


C-ISAM ist sozusagen das klassische ISAM-Produkt in der UNIX-Welt und bietet 
dem C-Programmierer Werkzeuge zur Speicherung von Daten nach dem XPG4- 
Standard von X/Open. 


INFORMIX-OnLine/FMWORM 


Mit INFORMIX-OnLine/FMWORM wurde das konventionelle Konzept eines Da- 
tenbankmanagementsystems um die Fähigkeit erweitert, Bilddateien oder große 
Mengen an Binärdaten (BLOBSs) als Teil der relationalen Datenbank abzuspeichern. 
Mit INFORMIX-OnLine/FMWORM wurde die Möglichkeit geschaffen, die Spei- 
cherung dieser Daten auf dem optischen Subsystem FMWORM,, einer Entwicklung 
von Siemens Nixdorf, zu integrieren. 


ESQL-C, ESQL-COBOL 


Datenbankzugriffe aus herkömmlichen Programmiersprachen der dritten Genera- 
tion sind über Precompiler-Produkte möglich, die sowohl eine statische als auch 
eine dynamische Einbindung der SOL-Anweisungen in normale C- bzw. COBOL- 
Programme erlauben. 


INFORMIX-SQL 


INFORMIX-SQL bietet dem Anwender den interaktiven Zugriff unter einer menü- 
gesteuerten Bedienoberfläche auf der Basis von SQL-Eingaben. Bestandteil des 
Produkts sind ein Listengenerator und ein Maskengenerator. Beide unterstützen die 
interaktive und die programmgesteuerte Nutzung. Mit Hilfe des Maskengenerators 
kann man sehr schnell einfache menügesteuerte Anwendungen entwickeln. Der Li- 
stengenerator bietet bei der Aufbereitung von Ergebnissen in Listenform höchste 
Funktionalität. 
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INFORMIX-4GL 


INFORMIX-4GLU/RDS/ID 


Die 4GL-Produkte von INFORMIX bieten eine komplette Entwicklungsumgebung 
(Compiler, Interpreter, Debugger) für die Entwicklung von Anwendungen auf Basis 
leistungsstarker Programmiersprachen der vierten Generation. Zusammen mit pro- 
zeduralen Sprachelementen sind Datenbankzugriff, Maskenerzeugung und Listen- 
generierung in einer homogenen Programmiersprache integriert, was zu einer er- 
heblichen Produktivitätssteigerung bei der Anwendungsentwicklung beiträgt. 


INFORMIX-4GL++ 


Die neuen Produkte der 4GL-Familie beinhalten insbesondere Erweiterungen zur 
Bedienung grafikfähiger Workstations und funktionale Erweiterungen für die ob- 
jektorientierte Anwendungsentwicklung. 


INFORMIX-4GL for ToolBus 


INFORMIX-4GL for ToolBus bietet eine leistungsfähige und einfach zu bedienen- 
de grafische Entwicklungsumgebung für die Entwicklung von Anwendungen mit 
den INFORMIX-4GL-Produkten. Das Produkt ist in INFORMIX-OpenCase/Tool- 
Bus integriert. 


INFORMIX-Connectivity-Lösungen 


Netzwerke spielen heute eine wichtige Rolle bei der Einbindung der verschiedenen 
Informationsbasen innerhalb eines Unternehmens auf PC-, Abteilungs- oder Unter- 
nehmensebene. Deshalb sind Produktlösungen gefragt, die den lokalen, aber auch 
den globalen Zugriff auf alle Informationen direkt vom Arbeitsplatz aus ermögli- 
chen. 


Mit dem Produkt INFORMIX-NET wird der entfernte Zugriff über heterogene 
Rechner auf Basis aller wesentlichen standardmäßigen Netzwerkprotokolle unter- 
stützt. Durch die Transparenz der Datenbanklokalisation eignet sich INFORMIX- 
NET bestens für den Einsatz von Client-Server-Lösungen in Netzwerken. 
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INFORMIX-STAR ist das Produkt von INFORMIX für den Datenbankzugriff in 
verteilter Verarbeitung. Es erlaubt dem Anwender Schreib- und Lesezugriffe auf 
mehrere Datenbanken auf verschiedenen Rechnern und garantiert gleichzeitig die 
Datenkonsistenz. Für das Anwendungsprogramm erscheint dabei der ferne Zugriff 
mit dem lokalen Zugriff identisch. INFORMIX-STAR regelt den Datenverkehr so- 
wohl über LANs als auch über WANSs. 


INFORMIX-Net-PC ermöglicht den Zugriff von DOS-Anwendungen auf die 
INFORMIX-Datenbanken im Netz. Die bereitgestellten Entwicklungswerkzeuge 
A4GL, ESQL und SQL unterstützen den Anwender auf vielfältige Art und Weise bei 
der Programmentwicklung. 


Darüberhinaus wird an Lösungen zur Unterstützung von heterogenen verteilten An- 
wendungen gearbeitet. INFORMIX ist ein führendes Mitglied der SQL-Access- 
Group und entwickelt gegenwärtig ein Produkt zur Anbindung von INFORMIX an 
die IBM-Welt auf Basis von DRDA (Distributed Relational Database Architecture). 
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INFORMIX-Anwendungen für den Netzeinsatz 


Abbildung 8-4: INFORMIX-NET und INFORMIX-STAR erlauben den fernen und verteilten Zugriff auf INFORMIX- 
Datenbanken. 
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Oracle 


Oracle ist mehr als nur ein relationales Datenbanksystem, es ist vielmehr eine abge- 
rundete Produktfamilie mit leistungsfähigen Werkzeugen zur Erstellung von Daten- 
banken und Anwendungen, zum komfortablen interaktiven Zugriff auf Daten und 
mit Gateways zur Anbindung an Fremdsysteme und anderes mehr. Die herausra- 
genden Leistungsmerkmale der Oracle-Produktfamilie sind: 


® eine allen Standards konforme SQL-Schnittstelle, 
® konsequente Client-Server-Architektur, 


® die Ablauffähigkeit auf allen relevanten Systemplattformen und dadurch nahezu 
unbeschränkte Portabilität und Konnektivität. 


Oracle Oracle 


MS-DOS, 05/2 BS2000 


MVS, VMS,.... 


Abbildung 8-5: Oracle ist auf unterschiedlichen Systemen ablauffähig, die über LAN oder WAN miteinander ver- 
bunden sind. 


Die wichtigsten Oracle-Produkte werden im folgenden kurz beschrieben. 
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Oracle DBMS 


Oracle DBMS ist ein leistungsfähiges, relationales Datenbanksystem mit breit an- 
gelegtem Funktionsspektrum; es eignet sich für alle Anwendungstypen von der 
komplexen Entscheidungsunterstützung bis hin zum klassischen OLTP-Betrieb. 


SQL*Net 
SQL *Net ist ein Baustein für ortstransparente Zugriffe auf verteilte Datenbanken, 
wobei alle gängigen Netzwerkprotokolle unterstützt werden. 

SQL*Connect 
SQL *Connect bildet den Gateway zu anderen Datenbanksystemen. 

Precompiler 
Hier handelt es sich um einen Precompiler für Embedded SQL in C, COBOL, 
FORTRAN und PL/1. 

PL/SQL 


Dies ist eine Sammlung Datenbankprozeduren mit Kontrollstrukturen und anderen 
Leistungsmerkmalen in einer höheren Programmiersprache. 


XA-Bibliothek 


Die XA-Bibliothek bietet einen Transaktionsmanager, basierend auf der von 
X/Open festgelegten XA-Systemschnittstelle. Unter Verwendung der XA-Schnitt- 
stelle können globale Transaktionen innerhalb mehrerer heterogener Computersy- 
steme und Datenbanken für eine große Zahl von parallel arbeitenden Anwendern 
koordiniert werden. 


SQL*Forms und SQL*Menu 


Dies sind Anwendungsgeneratoren für anspruchsvolle Bildschirmanwendungen. 
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SQL*Plus und SQL*ReportWriter 


Dies ist eine Interaktive SQL-Schnittstelle bzw. ein Werkzeug zur Listenerstellung. 


CASE*Dictionary, CASE*Designer und CASE*Generator 


Werkzeuge für Entwurf und Erstellung von Oracle-Datenbanken und -Anwendun- 
gen sowie zur Strukturierung von Abläufen. 


DRIVE - „Fourth Generation Language‘ von Siemens Nixdorf 
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Das Softwareprodukt DRIVE von Siemens Nixdorf umfaßt die Fourth Generation 
Language (4GL) DRIVE und das zugehörige Entwicklungssystem. Mit DRIVE 
werden OLTP-Anwendungen entwickelt, die SESAM-, UDS-, INFORMIX sowie 
zukünftig auch ORACLE- und DB2-Datenbanken verwenden. 


DRIVE bietet einen hohen Sprachkomfort. Dazu gehören 


® in die Sprache integrierte SQL-Anweisungen für die Definition von Datenban- 


ken (DDL), den Datenbankzugriff sowie für die Definition von temporären 
Sichten (Views). 


leistungsfähige Anweisungen für Bildschirmformate auf Alpha- und Grafikter- 
minals. 


umfassende Anweisungen für die Reporterstellung. 


Sprachmittel und Automatismen zur Transaktionssteuerung und Client-Server- 
Konfiguration. 


Funktionen, die es ermöglichen, internationalisierbare Anwendungen auf der 
Grundlage des NLS (Native Language System) zu erstellen. 


Das DRIVE-System besitzt eine einheitliche Schnittstelle zu den von ihm unter- 
stützten Datenbanksystemen auf der Grundlage des ISO-SQL-Standards. SQL als 
Abfragesprache ist voll in die DRIVE-Sprache integriert. DRIVE-Anwendungen 
sind sowohl im Einplatzbetrieb als auch unter Steuerung eines Transaktionsmoni- 
tors (UTM) ablauffähig, wobei für einen Wechsel zwischen den beiden Betriebsar- 
ten keinerlei Änderungen am DRIVE-Programm nötig sind. Eine Anwendung kann 
auch ohne Änderung am DRIVE-Programm auf einem BS2000- oder einem SINIX- 
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System eingesetzt werden. So können DRIVE-Programme, die auf einem BS2000- 
System ablaufen sollen, auch mit dem grafischen Entwicklungssystem in SINIX er- 
stellt und getestet werden. 


Damit sind DRIVE-Programme weitgehend unabhängig von dem zugrundeliegen- 
den Datenbank- und Betriebssystem. Sie werden sich daher ihre Einsatzfähigkeit 
und ihren Wert auf lange Sicht hin erhalten. 


Das Repository-System ERMS 


Das Repository-System ERMS (Enterprise Repository Management System) ist 
ein spezialisiertes Datenbanksystem für die Verwaltung von Metadaten (beschrei- 
bende Daten über Daten). Die informationstechnischen Beschreibungen eines Un- 
ternehmens und seiner Datenverarbeitungssysteme ist üblicherweise in vielfältigen 
Ablagen, vom Aktenordner bis zur Datenbank, verstreut. In einem Unternehmen 
muß dann versucht werden, die Qualität der Daten wie z.B. Aktualität, Konsistenz 
und Redundanzfreiheit durch organisatorische Vorschriften und Kontrollen zu errei- 
chen. In einem Repository werden dagegen alle diese Informationen konsistent und 
einheitlich verwaltet: Werkzeuge für Unternehmensmodellierung und 
Anwendungsentwicklung (z.B. Editoren, Generatoren), für den Systembetrieb (z.B. 
System- und Netzmanagement) sowie für Konfigurationsverwaltung, Projektmana- 
gement, Installation und Wartung können ihre beschreibenden Daten über die 
Schnittstelle IDDS im Repository-Management-System ERMS ablegen, modifizie- 
ren, lesen und löschen. Soweit die Informationen von übergreifender Bedeutung 
sind, muß die Struktur der Daten, also das Informationsmodell, zwischen den Re- 
pository-Anwendungen abgestimmt werden. 


Ein einheitliches Datenverwaltungssystem sowie ein redundanz- und widerspruchs- 
freies Informationsmodell gewährleisten die Qualität der Daten. Gleiche Sachver- 
halte können nicht mehrfach oder widersprüchlich eingegeben werden. Entwick- 
lungswerkzeuge können direkt auf die Ergebnisse der vorangegangenen 
Entwicklungsstufe zugreifen. Die einheitliche Modellierung nach dem Entity-Rela- 
tionship-Modell gestattet globale Recherchen und das Erkennen von Abhängigkei- 
ten. ERMS wird so zur Drehscheibe für sämtliche beschreibende Unternehmensin- 
formationen, für Softwareentwicklung, -betrieb und -pflege. 


171 


8 SINIX-Anwendungen im kommerziellen Großeinsatz 


Die Informationsmodelle, die dem Repository zugrunde liegen, können vom An- 
wender im Rahmen der Entity-Relationship-Modellierung frei gestaltet werden. 
Dadurch kann ERMS in eine spezifische Anwenderumgebung eingebunden wer- 
den. Durch Export/Import-Funktionen (auch für Schemata möglich) läßt sich 
ERMS mit anderen Data-Dictionary/Repository-Systemen zusammenschließen. 


Projekt- ACL Software- 
management produktions- 
umgebung 


Konfigurations- 
management 
Aufgaben- technische Werkzeuge 
Analyse- ..definitior Realisierung für Bedien- 
und Design- oberflächen 
werkzeuge 
Problem 
analyse ERMS Generatoren 
Repository- 
Unternehmens- Management C ı 
System || SEmpE St 
medellierung y Static Analyzer 
Debugger 
Test 
IDDS Testwerkzeuge | 
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System- 


Impactanalyse _ 
Reverse Engineering 
Netzwerk- 
management 
Hardware- 
Anwendungen] | management 


Abbildung 8-6: Das Repository ERMS enthält Informationen über den gesamten Lebenszyklus von Softwarepro- 
dukten. 


Über die Schnittstelle IDDS kann der Anwender nicht nur seine eigenen Program- 
me auf ERMS aufsetzen. Siemens Nixdorf setzt selbst Produkte darauf auf, wie z.B. 
das Open System CASE Environment (OÖSCE) oder das TRANSDATA-Communi- 
cation-Network-Management. 
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Bei den vielfältigen parallelen Zugriffen auf das Repository werden Datensicherheit 
und Konsistenz dadurch gewährleistet, daß ERMS seinerseits auf den bewährten 
Funktionen des relationalen Datenbanksystems INFORMIX aufsetzt. Unstruktu- 
rierte, umfangreiche Textinformationen (z.B. Sourcecode, Dokumentation) werden 
von ERMS im SINIX-Dateisystem abgelegt. Sie sind dabei voll in das Sicherheits- 
und Transaktionskonzept einbezogen. 


DB-Design/Generierung erzeugen 
Tabellenbeschreibungen. 

Das 4GL-Entwicklungswerkzeug 
referenziert sie. 


DB- 
Design/ 
Generator 


IDDS 


Repository 


Abbildung 8-7: Überlappende Informationsmodelle im ERMS-Repository und Auswertung über RADAR. 


Das Entity-Relationship-Modell ermöglicht eine einfache und intuitive Modellie- 
rung der Wirklichkeit. Der Anwender muß sie nicht in relationale Strukturen über- 
setzen, denn das wird vom System selbst erledigt. Über die grundlegenden Modell- 
elemente Entity-Typ, Relationship-Typ und Attribute hinaus können vielfältige 
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Konsistenzbedingungen für Beziehungen und Attribute definiert werden, die vom 
System auch überwacht werden. Die Einhaltung liegt dabei also nicht in der Verant- 
wortung der einzelnen Anwendungen. 


Da die Informationselemente, z.B. bei der Softwareentwicklung oder beim Konfi- 
gurationsmanagement, im Lauf der Zeit Veränderungen unterworfen sind, unter- 
stützt ERMS ein Versionskonzept für Entities. Deren Lebenszyklus, z.B. in Bezug 
auf Qualität und/oder Phase im Entwicklungsprozeß, kann durch Partitionen im Re- 
pository modelliert werden, welche die Entities dann durchwandern. 


Neben den Funktionen zur Eingabe und Manipulation bietet ERMS leistungsfähige 
Funktionen für die Wiedergewinnung von Informationen, die sich am hohen tech- 
nischen Stand der Datenbanktechnik orientieren. Die Möglichkeit, Suchabfragen 
mit vielfältigen Bedingungen zu koppeln oder sie auf ganze Beziehungspfade aus- 
zudehnen sowie mengenorientierte Operationen machen den Zugriff besonders ef- 
fektiv. Für den interaktiven Zugriff steht neben der Kommandoschnittstelle die for- 
matorientierte Ein-/Ausgabe ERMS-easy-access sowie der grafische Browser 
RADAR zur Verfügung. Mit RADAR können Repository-Schema und -Inhalt als 
Bäume, Netze, Tabellen oder Diagramme dargestellt werden. 


Die Programmschnittstelle IDDS ist als universelle, systemunabhängige Schnitt- 
stelle konzipiert. Ein verteiltes ERMS mit Client-Server-Architektur bietet über die 
identische IDDS-Schnittstelle Zugriff von SINIX-, BS2000- und PC-Systemen auf 
einen SINIX-Repository-Server. 


Wegen der zentralen Bedeutung der Repository-Schnittstelle ist hier eine Standar- 
disierung wünschenswert. ERMS entspricht heute weitgehend dem IRDS-Standard 
des American National Standards Institute (ANSI). Zukünftig wird ERMS auch 
eine Schnittstelle zur Objektverwaltung gemäß ECMA-PCTE anbieten, sobald die- 
se sich als De-facto- oder internationaler Standard durchsetzt. 


INFORMIX hat von Siemens Nixdorf eine Lizenz für das ERMS-Repository- 
System erworben und vermarktet ERMS nun erfolgreich für große OLTP-Systeme, 
als CASE-Repository und als Technologie, die wiederum von Drittfirmen zur Ent- 
wicklung zusätzlicher Anwendungen in Lizenz erworben werden kann. 
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PC-Integration 


SQL-Gateways 


Siemens Nixdorf bietet auf PC-Ebene innerhalb des OCIS-Bürosystems die 
ComfoWare-Produktfamilie als geeignete Bürolösung an. 


Das Produkt ComfoBase ist das Datenbanksystem innerhalb von ComfoWare und 
leitet sich von den SQL-Produkten der Gupta Technologies, Inc. ab. Siemens 
Nixdorf und Gupta Technologies, Inc. sind OEM-Partner. Neben der für ein PC- 
Produkt äußerst leistungsfähigen, relationalen Funktionaliät ist die Möglichkeit der 
Verbindung zu anderen Datenbanksystemen auf der Grundlage von Gatewaypro- 
dukten eine wichtige Eigenschaft der Produkte von Gupta. Dieses Konzept wurde 
durch den konsequenten Einsatz der Client-Server-Architektur verwirklicht, bei 
dem ein SINIX-Rechner die Rolle des zentralen Serversystems für die DOS-An- 
wendungen übernimmt, wodurch der Zugriff auf INFORMIX- (Serverrechner) bzw. 
SESAM- oder UDS-Datenbanken (Gatewayrechner) ermöglicht wird. 


Die Software-Produkte SQL Gateway/INFORMIX und SQL-Gateway/Mainframe 
(SESAM and UDS) werden derzeit auf Grundlage der Gupta-Gateway-Produkte 
portiert bzw. entwickelt. 


Die SQL-Gateway-Produkte werden auf einem SINIX-System installiert, das als 
Server-Rechner fungiert. Die Gateways haben die folgenden wesentlichen Aufga- 
ben: 


® Konzentratorfunktionen 

® Protokollkonverter (SQL, Call-Level, Transport) 
® Datentypanpassung 

® Fehlerbehandlung 


Die ersten Versionen der beiden Produkte dieser Familie wurden 1992 freigegeben. 
Das Ziel weiterer Entwicklungen wird neben der Portierung der Produkte auf ande- 
re Plattformen auch eine Funktionserweiterung und Anpassung an neue DBMS- 
Versionen sein. 
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MMC 


Das Software-Produkt MMC (Micro-Mainframe-Connection) wurde für SINIX in 
der Version 3.1 und für DOS in der Version 3.0 freigegeben. Das wichtigste Ziel von 
MMC ist es, den Zugriff auf BS2000-Datenbankmanagementsysteme (SESAM, 
UDS, GOLEM, INFPLAN, ADILOS, EASY, DVS) durch eine bequeme, automa- 
tisierte Verbindung zu den verschiedensten Anwendungen in SINIX- und DOS- 
Systemen zu erweitern. MMC Version 3.1 für SINIX kann darüber hinaus als Werk- 
zeug für die Unterstützung von interaktiven PC-Host-Verbindungen genutzt 
werden, in denen PCs als intelligente Arbeitsplätze eingesetzt werden. MMC er- 
möglicht SINIX-Systemen auch den Zugang zur IBM-Welt und damit zu den Da- 
tenbanken unter MVS. 


UPIC für MS-Windows 
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UPIC ermöglicht die Kommunikation zwischen MS-Windows und UTM-Anwen- 
dungen auf SINIX- oder BS2000-Systemen. Mit diesem Produkt können auch PCs 
Anwendungen im Rahmen der Transaktionsverarbeitung benutzen. 


9 Verfügbarkeit, Sicherheit und Qualität in SINIX 


9 Verfügbarkeit, Sicherheit und Qualität in SINIX 


Hohe Systemverfügbarkeit 


Verfügbarkeit ist eine Systemeigenschaft, die in den letzten Jahren vor allem im Be- 
reich der offenen Systeme an Bedeutung gewonnen hat. Die Verfügbarkeit eines 
Computersystems wird definiert als das Verhältnis der tatsächlichen Betriebszeit zur 
geplanten Betriebszeit. Betriebsausfallzeiten entstehen aus den unterschiedlichsten 
Gründen, etwa durch Störungen in der Stromversorgung, Anwenderfehler, Hard- 
ware- oder Softwarefehler. Hohe Verfügbarkeit nimmt gerade in einem Mehrplatz- 
system einen hohen Stellenwert ein, da bei einem Systemausfall eine größere An- 
zahl von Benutzern gleichzeitig betroffen ist. Hohe Verfügbarkeit wird erreicht, 
wenn sowohl Hardware- als auch Softwarekomponenten des Systems eine geringe 
Ausfallwahrscheinlichkeit aufweisen. Ein Ziel des Qualitätskonzepts von Siemens 
Nixdorf besteht darin, sowohl für Hardware als auch für Software eine geringe Aus- 
fallwahrscheinlichkeit zu erreichen. 


Neben den Qualitätsanforderungen an Hard- und Software kann die Verfügbarkeit 
durch zwei weitere Ansätze erhöht werden: Redundanz und Beschleunigung des 
Neustarts zur Wiederaufnahme des regulären Betriebs. Redundanz ermöglicht den 
Weiterbetrieb des Systems beim Ausfall einer Einzelkomponente. Ist ein Gesamt- 
ausfall jedoch unvermeidbar, muß der reguläre Betrieb möglichst schnell wieder- 
hergestellt werden können, um den Schaden so gering wie möglich zu halten. 
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Das SINIX-Konzept der hohen Verfügbarkeit beinhaltet: 


® Schutz vor Datenverlust und Inkonsistenzen 


® erhöhte Betriebssicherheit 


® Maßnahmen zur Vermeidung von Systemausfällen 


® kontrollierte Systembeendigung im Falle eines Ausfalls 


® verkürzte Wiederanlaufzeiten 


Eine Stärke von SINIX ist es, ein ganzes Spektrum an Funktionen zur Erhöhung der 
Verfügbarkeit anzubieten. SINIX geht in dieser Hinsicht weit über die Möglichkei- 
ten des Standard-UNIX hinaus. Durch diese Systemerweiterungen kann der An- 
wender die Verfügbarkeit des Gesamtsystems seinen Anforderungen entsprechend 
anpassen. 


SINIX-Basisverfügbarkeit 


Die im folgenden beschriebenen Funktionen sind Bestandteil jedes SINIX-Grund- 
systems. 


Eindeutige Systemmeldungen 
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Die ersten Maßnahmen, um einen Komponenten- oder Geräteausfall zu verhindern, 
sind eindeutige Warnmeldungen, die die Identifizierung und Lokalisierung eines 
Problems erleichtern. Die SINIX Systemmeldungen der Gerätetreiber sind nach ei- 
nem einheitlichen Schema aufgebaut. Eine eindeutige Meldungskennung erleichtert 
das schnelle Auffinden der zugehörigen Erklärung im Handbuch. Zusätzlich sind 
die Meldungen nach Gerätetypen klassifiziert. Jede Meldung ist mit einem Zeit- 
stempel und einer Fehlergewichtung versehen, die bereits erste Hinweise auf die 
Schwere eines Fehlers und seine möglichen Auswirkungen gibt. Die Fehlergewich- 
tungen sind so geordnet, daß für eine Schnelldiagnose bereits die für die Fehlerbe- 
hebung zuständige Instanz festgestellt werden kann (z.B. Operator, Teleservice, 
Wartung). Die Meldungen können sowohl auf der Konsole ausgegeben als auch in 
eine lokale Protokolldatei geschrieben werden. Im Netzverbund können sie zudem 
an einen zentralen Log-Server geleitet werden. 
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Verkürzung der Wiederanlaufzeiten 


Ein möglicher Nebeneffekt der gepufferten Ein- und Ausgabe kann ein Datenver- 
lust im Puffer sein, falls das System abrupt beendet wird, bevor der Puffer auf die 
Festplatte zurückgeschrieben werden konnte. Dadurch kann die Verwaltungsinfor- 
mation über die Dateisysteme auf der Festplatte inkonsistent werden. Unter UNIX 
wird bei einem Neustart des Systems das Dienstprogramm fsck (file system check) 
ausgeführt, um alle Dateisysteme auf ihre Konsistenz zu prüfen und gegebenenfalls 
zu rekonstruieren. Je nach Größe des Dateisystems und der Anzahl der Festplatten 
kann diese Überprüfung mehr als zehn Minuten in Anspruch nehmen. Siemens 
Nixdorf hat fsck weiterentwickelt, um die Wiederanlaufzeit auf SINIX-Systemen 
dadurch zu verkürzen, daß Dateisysteme auf verschiedenen Festplatten parallel 
überprüft werden. Auf diese Weise kann die Überprüfung eines Dateisystems auf 
ein Drittel der Zeit verkürzt werden. 


Systemstart von einer alternativen Festplatte aus 


Ein einfacher, aber sehr wirkungsvoller Mechanismus bei einem Ausfall der Sy- 
stemplatte besteht darin, eine alternative Festplatte bereitzuhalten, auf der die für ei- 
nen Systemstart notwendige Software vorhanden ist. Falls die Systemplatte einen 
schwerwiegenden Fehler aufweist, der den Weiterbetrieb des Systems verhindert, 
kann das Betriebssystem jederzeit von der zweiten Systemplatte aus gestartet wer- 
den. Die Ausfallzeiten können so sehr kurz gehalten werden. SINIX stellt diese 
Funktionalität durch ein Kommando zur Verfügung, das den Systemverwalter bei 
der Einrichtung einer alternativen Systemplatte unterstützt. Dabei werden die rele- 
vanten Systemteile der aktuellen Konfiguration auf die neue Festplatte übertragen. 
Gleichzeitig werden alle geräteabhängigen Informationen automatisch an die neue 
Systemplatte angepaßt. 
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Optimierung der Hauptspeicherabzüge 


Bei einem Systemausfall wird versucht, einen Abzug des Hauptspeichers vor der 
kompletten Beendigung auf die Festplatte zu schreiben (Systemdump). Bei größe- 
ren Hauptspeicherausbauten kann das Ablegen eines Speicherabzugs sehr zeitauf- 
wendig sein und viel Festplattenplatz in Anspruch nehmen. Auf SINIX-Systemen 
wird der Hauptspeicher bei einem Systemabsturz deshalb in komprimierter Form 
auf der Festplatte abgelegt. Die kompakte Version macht nur einen Bruchteil der ur- 
sprünglichen Größe des Hauptspeichers aus. Sie wird zuerst im Swap-Bereich der 
Systemplatte abgelegt. Die geringe Größe des Hauptspeicherabzugs und seine 
schnelle Zwischenspeicherung garantieren, daß die Ausfallzeit des Systems kurz 
gehalten und das System sofort wieder neu gestartet werden kann. Erst während des 
folgenden Neustarts des Systems wird der Speicherabzug in das Dateisystem über- 
nommen. Dort steht er für die spätere Diagnose zur Verfügung. 


Höhere Verfügbarkeit unter SINIX 


SINIX bietet eine Reihe zusätzlicher Produkte an, die die Systemverfügbarkeit für 
Installationen erhöhen, für die ein Höchstmaß an Verfügbarkeit unerläßlich ist. Die 
erhöhte Verfügbarkeit unter SINIX wird durch relativ preisgünstige und einfache 
Lösungen erreicht. Höhere Verfügbarkeit unter SINIX wird ohne exotische Hard- 
ware oder teure, hochspezialisierte Systeme erzielt. 


Sichern des Gesamtsystems 
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Schutz vor Datenverlust kann durch die regelmäßige Sicherung der Systemplatte 
auf externe Datenträger erreicht werden. SINIX stellt hierfür das Programm Backup 
zur Verfügung, das dem Systemverwalter eine denkbar einfache Benutzerführung 
bietet. Es können vollständige Festplatten oder ausgewählte Dateisysteme gesichert 
werden. Folgende Bandmedien werden unterstützt: Magnetbandkassetten, Exabyte- 
kassetten oder Magnetbänder. Nach einem Ausfall der Systemplatte ist eine schnel- 
le Wiederherstellung des Systems möglich, ohne daß eine Neuinstallation erforder- 
lich wäre. Eine Gesamtsicherung der Systemplatte ist insbesondere nach der 
Installation neuer Software-Pakete empfehlenswert. Eine Beschreibung des Daten- 
sicherungsprogramms Backup finden Sie im Abschnitt „Backup” auf Seite 104. 
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Unterbrechungsfreie Stromversorgung 


Um das Systemverhalten bei einer Unterbrechung der Netzspannung zu verbessern, 
kann das System mit einer unterbrechungsfreien Stromversorgung ausgestattet wer- 
den. Ein System, das mit einer unterbrechungsfreien Stromversorgung ausgestattet 
ist, stürzt nicht einfach ab, sobald ein Spannungsabfall registriert wird, sondern wird 
kontrolliert beendet. Die Daten werden gespeichert und das System wird vor dem 
Beenden in einen stabilen Zustand überführt. Dies erleichtert den Wiederanlauf und 
verkürzt die Ausfallzeit. Falls eine Netzstörung nur kurz andauert, kann die unter- 
brechungsfreie Stromversorgung die Beendigung des Systems sogar verhindern. 


Eine eingebaute Batterie bietet noch höheren Schutz vor Unterbrechungen in der 
Stromversorgung. Diese Batterie überbrückt Netzstörungen bis zu einer Dauer von 
einigen Minuten. Im Fall längerer Störungen wird das System kontrolliert beendet. 
Datenverluste können so minimiert werden. Sobald der Strom wieder zur Verfü- 
gung steht, kann das System neu gestartet werden. 


Spiegelplatten 


Mit dem Virtuellen Plattensubsystem VPSS können Datenbestände ganzer Festplat- 
ten oder Teile davon (Slices) mehrfach gespeichert werden. Durch diese Redundanz 
wird garantiert, daß bei Ausfall eines Datenträgers die Daten von einer anderen 
Festplatte gelesen werden und Anwendungen ohne Störung weiterarbeiten können. 
VPSS spiegelt zusätzlich einzelne Slices einer Festplatte auf andere Slices oder an- 
dere Festplatten. Dabei werden alle Schreibvorgänge, die auf der primären Festplat- 
te stattfinden, automatisch auch auf den sekundären Festplatten ausgeführt. So sind 
alle Festplattenslices, die zu einer Spiegelmenge gehören, immer auf einem einheit- 
lichen Stand. 


Sobald auf einer der Spiegelplatten oder dem Zugriffspfad ein Übertragungsfehler 
erkannt wird, werden die Datenzugriffe auf eine der redundanten Festplatten umge- 
lenkt. Der Anwender ist durch den Fehler nicht betroffen. Das Spiegelverfahren 
kann sowohl für SINIX-Dateisysteme als auch für Datenbanken eingesetzt werden, 
die auf zeichenorientierten Slices (raw Slices) organisiert sind. 
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Umschaltbare Festplatten 


Festplatten, die sich in einem eigenen, über SCSI angeschlossenen Peripherie- 
schrank befinden, können abwechselnd von jeweils einer von zwei Anlagen ange- 
sprochen werden. Dies funktioniert über einen Schalter, der von der Software kon- 
trolliert wird. Bei einem Systemausfall können die so verwalteten Datenbestände 
von einem zweiten System übernommen werden. 


In Kombination mit dem Spiegelplattensystem VPSS können Doppelrechnerkonfi- 
gurationen betrieben werden, die ein hohes Maß an Ausfallsicherheit gewährleisten. 


Standby-Konfigurationen 


OBSERVE 
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Noch höhere Verfügbarkeit kann mit Standby-Konfigurationen erzielt werden, die 
redundante Hardware ausnutzen. 


Ein zusätzlicher Schritt in einem System mit Standby-Konfiguration bildet die In- 
stallation von Software, die eine ständige Lebendüberwachung gewährleistet. Das 
Softwareprodukt OBSERVE von Siemens Nixdorf verfügt über diese Funktionali- 
tät. OBSERVE ist ein System zur Steuerung und Überwachung von Doppel- und 
Mehrrechnerkonfiguration. Die wichtigsten Peripheriegeräte werden über einen 
Schalter an beide Systeme angeschlossen, externe Festplatten sind umschaltbar an- 
gelegt. 


OBSERVE automatisiert den Vorgang der Rechnerüberwachung durch eine ständi- 
ge Lebendüberwachung der Rechner untereinander und übernimmt zusätzliche 
Überwachungsaufgaben. Falls einer der Rechner ausfällt, steuert OBSERVE die 
Übernahme seiner Aufgaben durch den Standby-Rechner. OBSERVE schaltet ex- 
terne Festplatten, Terminals, Drucker usw. dem Standby-Rechner zu. 


OBSERVE ermöglicht eine hohe Flexibilität in der Konfigurierung des Systems 
durch frei editierbare Konfigurationsdateien, editierbare Shellskripts zur Reaktion 
auf anwenderdefinierte Ereignisse sowie durch die Bereitstellung einer Schnittstelle 
(library) zur Erzeugung lokaler Überwachungsprogramme (Observer). So kann sich 
der Anwender die Verfügbarkeitsfunktionalität für seine Anforderungen maß- 
schneidern. Abbildung 9-1 zeigt den Einsatz von OBSERVE in einer Standby-Kon- 
figuration. 
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Abbildung 9-1: Eine SINIX Standby-Konfiguration mit unterbrechungsfreier Stromversorgung, einem SCSI Schal- 
ter, einem SUSI Schalter und dem Softwareprodukt OBSERVE. 
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Wesentliche Bestandteile eines Doppelrechnersystems sind 

® die Extension Box für SCSI-Platten, 

® serielle Umschalteinheiten, z.B. ein SUSI Schalter, 

® der Terminal-Server TACLAN 91863; 

® zwei Überwachungsleitungen zur gegenseitigen Rechnerüberwachung, 
® wahlweise unterbrechungsfreie Stromversorgung an jedem Rechner. 


Das Softwareprodukt OBSERVE besteht aus einer Reihe von Komponenten, wie in 
Abbildung 9-2 zu sehen ist. Das Hauptprogramm ist die zentrale Komponente und 
steuert den gesamten Ablauf von OBSERVE. Die Standardobserver PRT und 
EXIST sind Überwachungsprogramme, die mit OBSERVE ausgeliefert werden. 
Der Standardobserver PRT überwacht Drucker, während EXIST die Existenz von 
Prozessen überwacht. Eine Konfigurationsdatei enthält alle für die Überwachung 
notwendigen Daten über die Hardware- und Softwarekonfigurationen. Shellskripts, 
die vom Anwender erstellt werden, legen fest, wie auf Statusänderungen u.ä. rea- 
giert werden soll. 


Bei der Statusänderung von Objekten werden Objektreaktionsskripts ausgeführt. 
Bei Observerausfällen, die OBSERVE selbst erkennt, werden Observerreaktions- 
skripts ausgeführt. Für die Verwaltung von OBSERVE gibt es eine Reihe von Me- 
nüs und Kommandos, die entweder die Verwaltungsfunktionen selbst ausführen 
oder an das OBSERVE-Hauptprogramm weiterleiten. Ein Datenfernübertragungs- 
modul wickelt die Kommunikation zwischen den beiden Rechnern über Socketver- 
bindungen über TCP/IP ab, die bei der Konfigurierung angegeben wurden. Dieses 
Modul überwacht die Leitungen und erkennt den Ausfall des Partners (Lebendüber- 
wachung). Der Standardobserver ALIVE ermöglicht es, den Ablauf eines Prozesses 
(z.B. eines Anwendungsprogramms) zu überwachen. Dazu sind entsprechende Auf- 
rufe der Bibliothek libobsalive.a in das Anwendungsprogramm zu integrieren. 
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Abbildung 9-2: Die Komponenten von OBSERVE. 
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VxFS 
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Das VERITAS Filesystem (VxFS) ist ein Extent-basiertes Dateisystem für den Ein- 
satz auf SINIX-Systemen. Das bedeutet, daß VxFS auf zusammenhängenden Spei- 
cherbereichen auf der Festplatte (Extents) basiert, im Unterschied zu den physika- 
lisch verstreut liegenden Blöcken in herkömmlichen Dateisystemen. VxFES stellt 
Erweiterungen zur Verfügung, durch die SINIX in bestimmten kommerziellen An- 
wendungen noch besser einsetzbar ist. Die Haupteigenschaften des VxFS-Dateisy- 
stems sind: 


® schnelle Wiederherstellung des Dateisystems 


® Online-Verwaltung 


® Online-Sicherung 


® erweiterte Anwendungsschnittstelle 


® Modus für die erweiterte Datenintegrität 


® Verwendbarkeit als temporäres Dateisystem 


® Verwendbarkeit als Root-Dateisystem 


Das VxFS-Dateisystem ermöglicht die sekundenschnelle Wiederherstellung nach 
einem Systemausfall durch ein Fehlerverfolgungswerkzeug, das sogenannte Intent 
Logging. Das Intent Logging verfügt über eine zirkuläre Struktur, die noch nicht 
vollzogene Veränderungen in der Dateisystemstrukur ablegt, d.h. die Absicht einer 
Strukturänderung im Dateisystem wird aufgezeichnet. Diese Veränderungen wer- 
den in einer Protokolldatei aufgezeichnet. Bei der Wiederherstellung nach einem 
Systemausfall untersucht das VxFS-Kommando fsck (eine modifizierte Version des 
Standard-Kommandos fsck) diese Protokolldatei, um die Dateisystemoperationen, 
die zum Zeitpunkt des Systemabsturzes aktiv waren, aufzuheben oder zu vervoll- 
ständigen. Das Dateisystem kann dann wieder in das Gesamtsystem eingehängt 
werden, ohne daß die strukturelle Überprüfung des gesamten Dateisystems notwen- 
dig ist. Abgesehen davon, daß die Wiederherstellung des VxFS-Dateisystems in 
wenigen Sekunden abgeschlossen ist, bleibt das Intent Logging für den Anwender 
oder den Systemverwalter i.a. unsichtbar. Das VxFS-Dateisystem verfügt zudem 
über die Eigenschaft, die Festplattenauslastung zu verbessern (Defragmentierung) 
und die Größe des Dateisystems anzupassen, während es in Benutzung ist und für 
den Anwender verfügbar bleibt. 
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Das VxFS-Dateisystem erlaubt eine konsistente Datensicherung während des Sy- 
stembetriebs. Dabei macht VxFS von den Dateiverwaltungsstrukturen eines einge- 
hängten Dateisystems eine Kopie. Dies geschieht in sehr kurzer Zeit, da die Daten 
nicht komplett kopiert werden. Die Daten in dieser Kopie bleiben „eingefroren“, 
auch wenn zu einem späteren Zeitpunkt Änderungen am Dateisystem vorgenom- 
men werden. Den aktuellen Stand mit diesen Änderungen nimmt das Original an. 
So können die die Originaldaten weiter bearbeitet werden, während die „eingefro- 
rene“ Kopie gesichert wird. 


Im allgemeinen ist VxFS gegenüber Anwendungen transparent. Jede Anwendung, 
die auf einem bestehenden SINIX-Dateisystem ablauffähig ist, funktioniert mit 
VxFS identisch. 


Die unterschiedlichen Ansätze, die bisher beschrieben wurden, werden auch in Zu- 
kunft dazu benutzt werden, eine höhere Verfügbarkeit zu erzielen. Verfügbarkeit ge- 
winnt darüber hinaus für Systeme im Netzverbund durch verteilte Anwendungen, 
die auf Client-Server-Architekturen basieren. und den Einsatz mehrfach gehaltener 
Server an Bedeutung. In modernen Client-Server-Umgebungen wie derjenigen, die 
von DCE zur Verfügung gestellt wird, ist der Client einer Anwendung auf jedem Sy- 
stem im Netzverbund verfügbar, das diese Anwendung einsetzt (siehe Abschnitt 
„Verteilte Verarbeitung: DCE als Lösungsmodell” auf Seite 132). Die Abhängigkeit 
von einem einzigen System wird so reduziert. Server werden im allgemeinen auf 
mehreren Rechnern im Netzverbund gehalten. Durch den Einsatz standortunabhän- 
giger Namenskonventionen können Anfragen der Clients vom Server transparent 
umgeleitet werden. Dies wird notwendig, sobald ein Server nicht verfügbar ist, sei 
es, weil der Rechner, auf dem er sıch befindet, nicht in Betrieb ist oder weil eine 
Netzstörung aufgetreten ist. 
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Wenn große, einsatzkritische Anwendungen auf ein SINIX-System oder einen 
Netzverbund von SINIX-Systemen übertragen werden, stellen Benutzer, die an die 
Sicherheitstechniken in Mainframe-Systemen gewohnt sind, Fragen bezüglich der 
auf SINIX-Systemen verfügbaren Sicherheit. Der folgende Abschnitt gibt einen 
kurzen Überblick über die Systemsicherheit unter SINIX. 


Da diese Anwendungen üblicherweise in einem Netzverbund ausgeführt werden, 
sind sie von der Sicherheit des Netzes abhängig. In der Fachpresse wird des öfteren 
der Eindruck erweckt, Netzwerke offener Systeme seien besonders unsicher. Dies 
ist grundsätzlich nicht der Fall. Allerdings sind offene Systeme im Netzwerk den 
Angriffen von Hackern ausgesetzt. Es ist jedoch unbestreitbar, daß Jahre der Erfah- 
rung in der Abschirmung offener Systeme vor Hackern eine Reihe effektiver 
Sicherheitstechniken für Netzwerke hervorgebracht haben, sowie ein solides Wis- 
sen darüber, wie Netzwerke offener Systeme abgesichert werden können. 


Für den Fall, daß bisher unbekannte Sicherheitsprobleme im Netzverbund offener 
Systeme auftreten, steht weltweit eine große Anzahl von Spezialisten bereit, um 
diese zu bekämpfen. Zusätzlich gibt es globale Netze wie das Internet und elektro- 
nische Bulletinboards, über die Sicherheitsinformationen Online verbreitet werden. 
Die Sicherheit im Netzverbund offener Systeme ist so einer ständigen weltweiten 
Überprüfung unterworfen, die zu entsprechenden Qualitätsverbesserungen führt. 
Insbesondere die Veröffentlichung möglicher Sicherheitsprobleme führt zu deren 
Beseitigung. 


Über ein Netzwerk verbundene Informationssysteme haben bisher unerreichte 
Möglichkeiten der Informationsverarbeitung und Kommunikation eröffnet. Dies 
führte jedoch auch zur Abhängigkeit von der Sicherheit und der Verfügbarkeit die- 
ser Systeme. Mit dem Durchbruch UNIX-basierter Systeme auf dem kommerziel- 
len Markt wurden auch entsprechende Sicherheitsanforderungen an deren Entwick- 
lung gestellt und realisiert. Gleichzeitig wurden die Ergebnisse anderer Gruppen, 
die sich mit der Sicherheit der Informationstechnologie (IT-Sicherheit) befaßten, in 
den ständigen Entwicklungsprozeß UNIX-basierter Systeme wie etwa SINIX mit- 
einbezogen. 
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Aus den Evaluationskriterien für sichere IT-Systeme in den USA und Europa erga- 
ben sich wichtige technische Anforderungen. Der verbreitete Einsatz von UNIX- 
Systemen im Netzverbund erfordert die Integration von Sicherheitsstandards und 
De-facto-Standards in TCP/IP- und OSI-Netzwerken. Auch auf Workstations, die 
auf dem X Window System basieren, muß ein sicherer Betrieb möglich sein. Nicht 
zuletzt müssen auch für systemnahe Softwareprodukte wie z.B. Datenbanksysteme 
zusätzliche Sicherheitsfunktionen entwickelt werden. 


Basissicherheit unter SINIX 


Ein SINIX-System in der Standard-Konfiguration beinhaltet bereits erhebliche Si- 
cherheitsfunktionen. Das SINIX V5.4x Basissystem beispielsweise erfüllt die An- 
forderungen für die Sicherheitsklasse C1, wie sie im Anforderungskatalog der U.S. 
Regierung TCSEC (Trusted Computer Security Evaluation Criteria, auch unter 
dem Namen „Orange Book“ bekannt) formuliert wurden. Siemens Nixdorf testet 
die Effektivität dieser Funktionen regelmäßig im Rahmen der Qualitätssicherung 
des Betriebssystems. Die Mechanismen zur SINIX-Systemsicherheit umfassen: 


Benutzeridentifikation und Authentisierung 


Jeder Benutzer muß dem System bekannt sein (Identifikation) und bei der Anmel- 
dung am System durch die Eingabe eines nur ihm bekannten Paßwortes seine Iden- 
tität nachweisen (Authentisierung). 


Benutzergruppen 


Zusätzlich zur Identifikation einzelner Benutzer ermöglicht das System die Bildung 
von Gruppen. Mehrere Benutzer können so zu einer Gruppe zusammengefaßt wer- 
den, die auf bestimmte Daten gemeinsamen Zugriff hat. Dies ist sinnvoll für Unter- 
nehmensabteilungen wie beispielsweise eine Personalabteilung, deren Mitarbeiter 
auf eine gemeinsame Datenbank zugreifen müssen, die für andere Angehörige des 
Unternehmens jedoch nicht zugänglich sein soll. 


Zugriffsberechtigungen 


Jedem Datenobjekt, d.h. Dateien, Dateiverzeichnissen und den sogenannten Objek- 
ten der Interprozeßkommunikation wie Shared Memory, Semaphoren und Message 
Queues, werden bestimmte Attribute, die sogenannten Permissionbits, zugeordnet. 
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Zugriffsberechtigungen 


Jedem Datenobjekt, d.h. Dateien, Dateiverzeichnissen und den sogenannten Objek- 
ten der Interprozeßkommunikation wie Shared Memory, Semaphoren und Message 
Queues, werden bestimmte Attribute, die sogenannten Permissionbits, zugeordnet. 
Permissionbits regeln den Zugriff auf das jeweilige Datenobjekt. Folgende drei Zu- 
griffsarten werden unterschieden: lesender, schreibender und ausführender Zugriff. 
Bei der Entscheidung, wer auf ein Objekt zugreifen darf, teilt das System alle Be- 
nutzer in drei Klassen ein: den Eigentümer, die Gruppe und die übrigen Benutzer. 
Für jede dieser Benutzerklassen können die Zugriffsberechtigungen auf ein Objekt 
getrennt festgelegt werden (Lese-, Schreib- und Ausführberechtigung). 


Privilegierte Benutzer 


Prozesse 
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Sicherheitsrelevante Systemveränderungen wie etwa die Verwaltung von Zugriffs- 
rechten oder die Einrichtung neuer Benutzer können nur von einem privilegierten 
Benutzer, dem Systemverwalter, durchgeführt werden. 


Jeder Prozeß im System besitzt einen eigenen Adreßraum, der von den Adreßräu- 
men anderer Prozesse abgegrenzt ist. Die Kommunikation zwischen unabhängigen 
Prozessen ist nur über spezielle Mechanismen möglich, die wiederum durch die Re- 
gelung der Zugriffsrechte überwacht werden. 
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Erweiterte Sicherheitsfunktionen unter SINIX 


SINIX-Versionen mit erweiterter Sicherheit bieten wichtige zusätzliche 
Sicherheitsfunktionen wie Zugriffskontrolle, Rollenkonzept und Protokollierung. 
Im Rahmen von DCE werden zusätzliche Sicherheitsfunktionen für verteilte Syste- 
me in SINIX integriert. SINIX-Systeme werden dadurch mit mächtigen zusätzli- 
chen Netzwerk-Sicherheitsfunktionen wie Authentisierung, Authorisierungsprü- 
fung und Datenverschlüsselung ausgestattet (siehe Abschnitt „DCE-Komponenten” 
auf Seite 135). Zusätzlich wird die Zugangskontrolle in SINIX-Systeme durch 
Chipkarten unterstützt. In Zukunft wird der Arbeitsschwerpunkt auf erweiterten Si- 
cherheitsfunktionen (SINIX-ES, basierend auf UNIX SVR4-ES der UNIX System 
Laboratories,) und allgemeinen Sicherheits-APIs (Application Programming Inter- 
faces) liegen. Parallel dazu verfolgt Siemens Nixdorf die Kompatibilität und Inte- 
roperabilität von SINIX in offenen Systemen durch die aktive Mitarbeit an der Ent- 
wicklung von Sicherheitsstandards. 


Neben der Sicherheit im Basissystem existieren zwei Ansätze zur weiteren Verbes- 
serung der Sicherheitseigenschaften von SINIX: 


® Weiterentwicklung der Sicherheitsfunktionen zu einem System, das einer 
Evaluationsinstanz zur Zertifizierung vorgelegt werden kann. 


® Bereitstellung zusätzlicher Funktionen, die die Basissicherheit erhöhen. 


Eine Beschreibung evaluierter Produkte finden Sie im Abschnitt „Evaluierte Sicher- 
heit unter SINIX” auf Seite 197. Der folgende Abschnitt beschäftigt sich mit zwei 
Aufsatzprodukten, die zusätzlich zur SINIX-Basisversion installiert werden können 
und jeweils zusätzliche Sicherheitsfunktionalität zur Verfügung stellen. 
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Der Schwachpunkt bei der Sicherheit von IT-Systemen ist die Authentisierung. 
Authentisierung eines Benutzers bedeutet, daß dieser während der Anmeldung am 
System seine Identität nachweist. Dieser Nachweis wird in herkömmlichen Syste- 
men meist mittels eines Paßworts erbracht, von dem man annimmt, daß es nicht 
leicht zu erraten und nur dem Benutzer bekannt ist. Die Praxis zeigt jedoch, daß 
Paßwörter nicht sicher sind: 


© Paßwörter sind häufig leicht zu erraten, wie etwa der Name des Ehepartners, der 
Name des Benutzers, der Rechnername oder einfache Variationen dieser Na- 
men, z.B. durch das Anfügen einer Ziffer. 


® Das Paßwort wird aufgeschrieben und die Notiz offen liegen gelassen, beispiels- 
weise in der Nähe eines Terminals. 


® Es sind Programme verfügbar, auch über Public Domain, die ausgefeilte Aktio- 
nen zum intelligenten Erraten von Paßwörtern durchführen. Diese Programme 
greifen auf ein elektronisch zugängliches Wörterbuch zurück, dessen Inhalt va- 
riiert werden kann. 


® Daoffene Systeme häufig im Netzverbund verwendet werden, findet die Anmel- 
dung am System meist über das Netzwerk statt. In diesem Fall wird das Paßwort 
möglicherweise unverschlüsselt über das Netz übertragen und damit für andere 
leicht lesbar und späterem Mißbrauch ausgesetzt. 


® Ein häufiger, besonders schwerwiegender Fall liegt bei der Anwendung von 
Netzkommandos wie remote copy vor. Diese verlangen, daß die Paßwortabfrage 
im Zielrechner unterdrückt wird und lediglich durch Prüfung des lokalen Rech- 
ners und des Namens des Benutzers, der das ferne Kommando ausführen will, 
ersetzt wird. Dieser Mechanismus bewirkt zugleich, daß die Anmeldung am fer- 
nen Rechner ebenfalls ohne Paßwortabfrage erfolgt. 


ASECO unterbindet all diese Schwachpunkte: der Zugang zu SINIX-Systemen 
wird von ASECO mit Hilfe einer Chipkarte geregelt, die kryptographische Ver- 
schlüsselungen unterstützt. 


Ein Benutzer, der sich an einem durch ASECO geschützten SINIX-System anmel- 
den will, muß im Besitz einer Chipkarte sein. Zusätzlich muß er die nur dieser Chip- 
karte bekannte PIN (Personal Identification Number) kennen, um die Anmeldung 
erfolgreich durchzuführen. 
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Die auf der Chipkarte gespeicherte geheime Information ist nicht lesbar. Dies gilt 
insbesondere für die kryptographischen Schlüssel. Die Chipkarte benutzt einen 
kryptographischen Algorithmus für diese geheimen Schlüssel. Das bedeutet, daß es 
keinerlei Möglichkeit gibt, den geheimen Schlüssel der Chipkarte zu lesen. Die der 
Chipkarte bekannte PIN ist ebenfalls nicht lesbar, sie kann jedoch geändert werden, 
um die Gefahr eines möglichen Mißbrauchs der Chipkarte auszuschließen. 


Authentisierung ist ihrem Prinzip nach zweiseitig. Eine Instanz erbringt gegenüber 
einer zweiten Instanz den Nachweis, daß sie über die von ihr vorgegebene Identität 
verfügt. Da es sich bei der einen Instanz um die Chipkarte handelt, muß die zweite 
Instanz - der Rechner - ebenfalls über denselben geheimen Schlüssel verfügen. Ein 
spezielles Sicherheitsmodul enthält diesen Schlüssel inklusive des Verschlüsse- 
lungsalgorithmus. 


Prinzipiell findet die Authentisierung des Chipkartenbenutzers in zwei Schritten 
statt: 


l. Nach Einlegen der Chipkarte weist sich der Benutzer durch Eingabe seiner PIN 
gegenüber der Chipkarte aus. 


2. Anschließend wird der eigentliche Authentisierungsmechanismus zwischen 
Chipkarte und Sicherheitsmodul des Rechners durchgeführt. Die Authentisierung 
wird seitens der Chipkarte nur ausgeführt, wenn die vorangegangene PIN-Prüfung 
erfolgreich verlaufen ist. 


Der Authentisierungsmechanismus beruht darauf, daß Zufallszahlen verschickt 
werden, die vom jeweiligen Partner verschlüsselt quittiert werden müssen (Challen- 
ge-Response-Verfahren). 


Ein Mißbrauch der Chipkarte wird dadurch ausgeschlossen, daß der Authentisie- 
rungsmechanismus erst gestartet wird, nachdem die Chipkarte die Identität des Be- 
nutzers mittels der PIN festgestellt hat. 
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Abbildung 9-3: ASECO stellt für lokale und ferne SINIX-Systeme eine Sicherheitsschnittstelle für Chipkartenbe- 


nutzer zur Verfügung. 
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Weitere Leistungen von ASECO: 


Der von ASECO verwendetet Mechanismus zur Authentisierung steht auch als 
Programmierschnittstelle (API) zur Verfügung und kann so für kundeneigene 
Anwendungen eingesetzt werden. Der Zugang zu diesen Anwendungen kann 
dann mit Hilfe der Chipkarte kontrolliert werden. 


Ein weiters API gibt es für die Chipkartenüberwachung. Diese ermöglicht die 
Suspendierung einer Sitzung, sobald die Chipkarte aus dem Chipkartenterminal 
entfernt wird. Eine Fortsetzung der Sitzung ist erst möglich, wenn die Chipkarte 
erneut eingelegt und der Identifizierungs- und Authentisierungsvorgang erfolgt 
ist. 


ASECO und auch alle Anwendungen, die das ASECO-API verwenden, sind 
auch im Netzverbund funktionsfähig; Chipkarten-Terminals und Benutzer-Ter- 
minals können auch an ferne Rechner im Netz angeschlossen werden. Dies ist 
von großer Bedeutung, da so ein Angriff verhindert wird, der durch Abhören ei- 
nes im Netz übertragenen Paßwortes leicht möglich gewesen wäre. 


Sowohl die Verbindung zwischen Sicherheitsmodul und System als auch die 
Verbindung zwischen System und Chipkarte kann ohne Verletzung der Sicher- 
heit „abgehört‘“ werden. Im Authentisierungsverfahren werden lediglich Zu- 
fallszahlen und verschlüsselte Zufallszahlen über die Verbindung geschickt. 


Der Anschluß der Chipkarte an das System erfolgt über ein Chipkarten-Termi- 
nal, das neben dem physikalischen Anschluß der Chipkarte auch eine Tastatur 
besitzt, über die die PIN eingegeben wird. Die PIN wird dann an die Chipkarte 
zur Überprüfung weitergeleitet. Das Chipkarten-Terminal ist so konstruiert, daß 
die Verbindung zwischen Terminal und Chipkarte nicht abgehört werden kann. 
Die PIN ist ein Geheimnis zwischen der Chipkarte und ihrem rechtmäßigen Be- 
nutzer. Die PIN kann vom Benutzer über das Chipkartenterminal geändert wer- 
den. 
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Systeme, die der Sicherheitsklasse C2 des Orange Book entsprechen, bieten weitaus 
höhere Sicherheit als herkömmliche Systeme. Gleichzeitig halten sich der finanzi- 
elle Mehraufwand sowie der Mehraufwand für höhere Sicherheitsfunktionen, der 
mit der Verwaltung und Anpassung von Aufsatzprodukten verbunden ist, in Gren- 
zen. Bei näherer Betrachtung eines auf UNIX SVR4-basierenden Systems wie 
SINIX muß festgestellt werden, daß die wichtigste fehlende Funktionalität, um C2 
zu genügen, eine Komponente zur Protokollierung ist. Das Produkt Audit bietet die- 
se Funktionalität. Mit Hilfe von Audit können sicherheitsrelevante Ereignisse, so- 
genannte Events, protokolliert werden. So kann der Systemverwalter später nach- 
vollziehen, was sich zu einem beliebigen Zeitpunkt im System ereignete. 


Beispiele für Events, die in SINIX protokolliert werden: 


add_usr neue Benutzerkennung einrichten 
date Systemdatum ändern 
open_wr Datei zum Schreiben öffnen 


dac_mode Zugriffsrechte einer Datei ändern 
login Anmeldung eines Benutzers. 


Events werden im Kern des Betriebssystems beim Ablauf bestimmter Systemaufru- 
fe (z.B., date, open, chmode) oder vertrauensrelevanter Kommandos (z.B., add_usr, 
login) erzeugt. So können sicherheitsrelevante Events (z.B. Zugangsversuche) er- 
kannt und überwacht (protokolliert) werden. 


Die Schnittstelle, die von den Kommandos verwendet wird (auditdmp), ist be- 
schrieben und kann auch von vertrauenswürdigen Anwendungen verwendet wer- 
den. Die Vertrauenswürdigkeit einer Anwendung wird dadurch sichergestellt, daß 
nur der Systemverwalter die entsprechende Berechtigung vergeben kann. Kriterien, 
die über eine Protokollierung von Events entscheiden, werden ebenfalls vom Sy- 
stemverwalter festgelegt. Dabei hat er die Möglichkeit, die Kriterien systemweit für 
alle Benutzer oder aber speziell für bestimmte Benutzer festzulegen. 
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Die Daten werden in einem kompakten Format auf ein Speichermedium geschrie- 
ben. Zur Auswertung steht ein spezielles Kornmando (auditrpt) zur Verfügung, das 
die Daten in ein lesbares Format umwandelt und einfache Selektionen ermöglicht 
(z.B. alle Events für einen Benutzer). Als Speichermedien werden Dateien benutzt. 
Zur Verwaltung des Audit-Systems (z.B. Ein- und Ausschalten) steht eine Reihe 
von Kommandos zur Verfügung. Die Aktionen können jedoch auch menügesteuert 
über das Bediensystem zur Systemverwaltung ausgeführt werden. 


Evaluierte Sicherheit unter SINIX 


Bereits in den 60er Jahren begannen in den USA vorbereitende Arbeiten zur Ent- 
wicklung sicherer IT-Systeme und der zu diesem Zweck notwendigen Sicherheits- 
funktionen. Diese Arbeiten führten 1983 schließlich zur Veröffentlichung eines Kri- 
terienkatalogs, den „Trusted Computer System Evaluation Criteria” (TCSEC, 
Orange Book). 1985 wurde eine aktualisierte Version herausgegeben. Für das Oran- 
ge Book verantwortlich zeichnet das National Computer Security Center (NCSC). 
Dort werden auch Evaluationen durchgeführt. 


In Deutschland setzten entsprechende Aktivitäten 1989 mit der Gründung der Zen- 
tralstelle für Sicherheit in der Informationstechnik (ZST) ein. Im gleichen Jahr ver- 
öffentlichte auch die ZSI Sicherheitskriterien, das sogenannte Grünbuch. Seit 1991 
ist das Bundesamt für Sicherheit in der Informationstechnik (BSI), das aus der ZSI 
hervorging, für die Evaluation und Zertifizierung sicherer IT-Systeme zuständig. 
Ebenfalls im Jahr 1991 wurde ein entsprechendes Evaluationshandbuch veröffent- 
licht. SINIX-S V5.22 wurde als erstes UNIX-System in Deutschland evaluiert und 
zertifiziert. 


1990 veröffentlichten Frankreich, die Niederlande, Großbritannien und Deutsch- 
land erstmals ihre gemeinsamen IT-Sicherheitskriterien (ITSEC). Diese befinden 
sich als Version 1.2 in einer zweijährigen Erprobungsphase. Es ist zu erwarten, daß 
diese Kriterien europaweit Einsatz finden werden. Die Evaluierungs- und Zertifika- 
tionsverantwortung liegt bei den nationalen Behörden. Inzwischen wurden auch 
privatwirtschaftlich organisierte Unternehmen zugelassen, um Sicherheitsevalua- 
tionen durchzuführen. 
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Während sich TCSEC und ITSEC strukturell stark unterscheiden, sind die zu unter- 
suchenden Sicherheitsfunktionen sehr ähnlich. Nach TCSEC sind die Funktionen 
hierarchisch von D als schwächster Gruppe über Cl, C2, Bl, B2, B3 bis zu A als 
stärkster Gruppe geordnet. In Gruppe C werden speziell Protokollierungsfunktio- 
nen, Zugangskontrolle und benutzerdefinierte Zugriffskontrolle untersucht. In 
Gruppe B kommen systemdefinierte Zugriffskontrolle und Rollendefinition hinzu. 
Die strukturellen Unterschiede zwischen ITSEC und TCSEC liegen darin, daß: 


® imITSEC qualitative Eigenschaften bezüglich der Wirksamkeit der Mechanis- 
men und der Qualität ihrer Realisierung in eigenen Klassen/Kriterien festgelegt 
sind und 


® im ITSEC die Funktionen so allgemein gefaßt wurden, daß auch Sicherheit in 
Datenbanken und in der Kommunikation sowie Zuverlässigkeitseigenschaften 
abgedeckt werden. 


Weitere Informationen über Sicherheitsstandards finden Sie in Anhang A dieses Bu- 
ches. Zusätzlich zu den bereits genannten Funktionen des Basissystems wird spezi- 
ell im Rahmen offener Systeme an sicheren, X-basierten Workstations und sicheren 
verteilten Systemen gearbeitet. Darüber hinaus haben in den USA gemeinsame Ar- 
beiten des NIST (National Institute for Standards and Technology) und der NSA 
(National Security Agency) mit der Zielsetzung begonnen, TCSEC (das Orange 
Book) durch einen neuen Standard zu ersetzen. Ein erster Entwurf der Federal Cri- 
teria wurde bereits veröffentlicht. 


Aufsetzend auf bestehende Sicherheitsmechanismen des SINIX-Basissystems bie- 
tet SINIX-S Funktionen, die den C2-Anforderungen des Orange Book entsprechen. 
Das System wurde beim BSI einer dem Grünbuch entsprechenden Evaluation un- 
terzogen und erzielte eine Einstufung in den Klassen F1/Q2. Der Evaluationsbericht 
ist über alle Geschäftsstellen von Siemens Nixdorf zu beziehen. Da Zugriffskontrol- 
listen nach ITSEC zwingend vorgeschrieben sind, konnten die Anforderungen der 
Funktionsklasse F2 nicht vollständig erfüllt werden. Wesentliche funktionale Er- 
weiterungen gegenüber dem SINIX-Basissystem bestehen u.a. in: 


SINIX-ES 
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® der Einführung eines Audittrails zur Protokollierung und späteren Nachvoll- 
ziehbarkeit sicherheitsrelevanter Operationen sowie 


® der Einführung eines Rollenkonzepts (Vergabe von Privilegien) zur Trennung 
von Systemverwalter, Verwalter von Sicherheitsbelangen und Operator. 


Mit dem XPG3plus-Zertifikat ist SINIX das einzige UNIX-System, das auch ein of- 
fizielles Sicherheitszertifikat entsprechend Q2 (Grünbuch) trägt. 


SINIX-ES ist das Ergebnis einer Referenzportierung von UNIX SVR4.ES 
(Enhanced Security) auf Intel 386/486 Plattformen. UNIX SVRA4.ES bietet Sicher- 
heitsfunktionen entsprechend der Klasse B2 des Orange Book und wird derzeit vom 
NCSC evaluiert. 


Folgende wesentliche Eigenschaften unterscheiden SINIX-ES von C2- oder Bl-Sy- 
stemen: 


® Sicherer Systemzugang sichert den Vorgang der Anmeldung am System gegen 
Scheinprogramme, die eine Anmeldung vorspiegeln und sich dadurch Paßwör- 
ter erschleichen. 


® Privilegien ermöglichen eine Trennung von Rollen im System. Systemverwal- 
ter, Verwalter von Sicherheitsbelangen und Operator sind vordefiniert, weitere 
Rollen sind jedoch konfigurierbar. Alle Systemprogramme unterstützen das 
Prinzip der minimalsten Privilegien, das die jeweils gültigen Privilegien auf das 
kleinste notwendige Maß beschränkt. 


® Jeder Systemressource wird eine Sicherheitsklasse zur Unterstützung der 
systemdefinierten Zugangskontrolle zugewiesen. 


® Der Kern wurde überarbeitet, um durch eine klare Modulstruktur die Evaluati- 
onsanforderungen erfüllen zu können. Die Anzahl globaler Variablen wurde re- 
duziert. Der Kern wurde überprüft, um sicherzustellen, daß die Software keine 
„Hintertüren“ enthält, die eine nicht vorgesehene Nutzung seiner Funktionalität 
ermöglichen. 


Die unterstützte Sicherheitspolitik ist formal beschrieben. Ausführliche Designdo- 
kumentation steht zur Verfügung. Um die Sicherheitsfunktionen zu testen, wurde 
eine spezielle Sicherheitstestfolge entwickelt. 


199 


9 Verfügbarkeit, Sicherheit und Qualität in SINIX 


Qualitätsstandards 


200 


Das Betriebssystem SINIX konnte bisher die ständig wachsenden Anforderungen 
der Kunden an die Qualität erfüllen und wird dies auch weiterhin tun. Ebenso erwies 
sich SINIX der zunehmenden Komplexität der heute üblichen Softwarekonfigura- 
tionen gewachsen. Schon sehr bald machte unser Erfolg in dieser Hinsicht SINIX 
zu einem ausgereiften Betriebssystem für den kommerziellen Einsatz. Dies bedeu- 
tete die Abkehr von der herkömmlichen Einschätzung, UNIX-basierte Systeme sei- 
en als Betriebssysteme nur für Experten oder technische Anwender geeignet. Die 
„Kommerzialisierung“ von SINIX wurde auf mehreren Wegen erreicht, u.a. durch 
die Übernahme von Prozeßschritten des Software-Engineering, die sich bereits im 
Bereich der Mainframe-Systeme bewährt hatten. Gleichzeitig wurden die Aufwän- 
de für die Qualitätssicherung auf über 30% der Gesamtentwicklungskosten erhöht. 
Die positiven Ergebnisse dieser Maßnahmen zeigen sich an geringeren Kosten für 
Wartung und Gewährleistung, die Siemens Nixdorf für SINIX vorweisen kann, 
trotz einer wachsenden Palette von SINIX-Produkten und steigender Marktdurch- 
dringung. 


Dem Druck des Wettbewerbs zur Unterstützung neuer Hardware und zusätzlicher 
Softwarefunktionalität in einem beschleunigten Innovationszyklus kann nur durch 
eine sehr hohe Entwicklungsproduktivität, eine große Flexibilität der Mitarbeiter 
und ein effektives Projektmanagement begegnet werden, das auf einem technolo- 
gisch ausgereiften Entwicklungsprozeß basiert. 


Siemens Nixdorf hält im Wettstreit zwischen „Time to Market“ und Qualität letzt- 
endlich jedoch am Leitspruch „Qualität vor Termin vor Funktion“ fest. Darunter 
verstehen wir, daß Termintreue wichtiger als zusätzliche Funktionalität ist, Qualität 
jedoch stets oberste Priorität hat, selbst wenn dies bedeuten sollte, daß Zeitpläne 
nicht genau eingehalten werden können. Keinesfalls sollen aufgrund von Termin- 
druck Produkte ausgeliefert werden, die unsere anspruchsvollen Qualitätsstandards 
nicht erfüllen. Dieses Konzept ist in die internen Verträge zwischen Produktplanung 
und Entwicklung eingeflossen. Es wird außerdem durch die organisatorische Tren- 
nung der Bereiche Qualitätssicherung und Entwicklung unterstützt. 


9 Verfügbarkeit, Sicherheit und Qualität in SINIX 


Die Testmethodik, die vor der Freigabe einer SINIX-Version Anwendung findet, er- 
höht sukzessive die Komplexität der getesteten Software- und Hardware-Umge- 
bung, bis eine komplexe Software-Umgebung und eine komplexe Hardware- 
Konfiguration erreicht sind, in denen das Zusammenwirken von Datenbank- 
anwendungen, Compilern, Netzwerkprogrammen und weiteren Produkten sicher- 
gestellt ist. So beschränkt sich die herausragende Qualität von SINIX-Systemen 
nicht nur auf das Betriebssystem selbst, sondern umfaßt auch ein breites Spektrum 
integrierter Produkte. 


Wesentliche Merkmale guter Qualität sind: 


® die hohe Verfügbarkeit der Software; Behebung möglichst aller Fehler vor der 
Kundenfreigabe (weniger als 2% erwarteter Fehler nach der Kundenfreigabe) 


® einheitliche Bedienoberflächen von Low-End- bis zu High-End-Systemen 
® hochwertige Dokumentation 


® die Möglichkeit einer Ferndiagnose bei eventuell auftretenden Problemen sowie 
schnelle Bereitstellung von Korrekturen 


® die Fähigkeit, Kundenanforderungen umzusetzten und die regelmäßige Bereit- 
stellung funktionaler Upgrades 


® überzeugende Leistung auch bei hohen Anforderungen an die Ressourcen 


® ein gutes Preis-/Leistungsverhältnis. 
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Der Entwicklungsprozeß für SINIX-Systeme wird durch das Siemens Nixdorf 
Methodenhandbuch (MHB) geregelt. Das MHB definiert eine Entwicklungsmetho- 
dik, die innerhalb von Siemens Nixdorf für die gesamte Entwicklung von BS2000- 
und SINIX-Systemen Anwendung findet. Diese Methodik ist in mehr als 15 Jahren 
herangereift und hat sich in diesem Zeitraum auch bewährt. Die Festlegungen des 
MHB werden regelmäßig überprüft und aktualisiert, um den Fortschritten in der 
Software-Entwicklungsmethodik gerecht zu werden. Zusammen mit den Regelun- 
gen des Qualitäts-Management-Handbuchs von Siemens Nixdorf entsprechen sie 
der international anerkannten Qualitätsnorm ISO 9001. 


Der chronologische Prozeß bei der Entwicklung eines Produkts beginnt mit dem 
Zeitpunkt des innerbetrieblichen Vertragsabschlusses zwischen der Systemplanung 
und der Entwicklung. In diesem Vertrag wird das Produkt, das entwickelt werden 
soll, so genau wie möglich definiert, Kundenanforderungen und sonstige Entwick- 
lungsziele werden festgehalten. Der Entwicklungsprozeß wird gemäß dem MHB 
durch die Definition von Meilensteinen in eine zeitliche Folge von Prozeßschritten 
zerlegt, ebenso werden die entsprechenden Verantwortlichkeiten geregelt. Die Er- 
gebnisse jedes Schrittes werden durch verschiedene Verfahren verifiziert (Fagan- 
Reviews, Development Document Review). Protokolle jedes Verifizierungsverfah- 
rens werden über den entsprechenden Standard erstellt und archiviert. 


Bereits zum Zeitpunkt der Planung wird das Produkt, das entwickelt werden soll, in 
einzelne Teilaufgaben strukturiert. Diese werden entweder in parallelen oder genau 
aufeinander abgestimmten Entwicklungsteilschritten bearbeitet. Gleichzeitig wird 
ein erster Terminplan und ein Prognosemodell über die Fehler, die während der 
Testphase gefunden werden sollen sowie über die zu erwartende Leistung komple- 
xerer Produkte erstellt. Falls ein Produkt auf Fremdcode basiert, wird die Qualität 
dieses Fremdcodes möglichst schon im Vorfeld der eigentlichen Entwicklung veri- 
fiziert. 


Regelmäßig stattfindende Produkt-Status-Meetings kontrollieren den Projektfort- 
schritt bei möglichst genauer Einhaltung des Produktplans. Notwendige Entschei- 
dungen werden von einer genau festgelegten Gruppe innerhalb des Managements 
getroffen. Elektronische Post (E-Mail) und andere Methoden werden angewandt, 
um offene und effiziente Informationskanäle bereitzustellen. 
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Die CASE-Verfahren, die bei der SINIX-Entwicklung eingesetzt werden, gewähr- 
leisten eine gleichbleibend hohe Produktivität. Sie sind standortunabhängig und er- 
füllen die Voraussetzung für die dezentrale Entwicklung eines gemeinsamen Pro- 
dukts. Die derzeitigen Entwicklungsstellen von Siemens Nixdorf sind München, 
Paderborn, Namur (Belgien), Wien (Österreich) und Burlington (USA). 


Es werden leistungsfähige innerbetriebliche Werkzeuge verwendet, darunter: 


SMS 


Ein Sourcecode-Verwaltungssystem, das die Arbeit an demselben Code von ver- 
schiedenen Standorten aus erlaubt und Cormmon-Source-Strukturen unterstützt. 
SMS wird benutzt, um mehr als 100.000 Dateien mit einem Speicherbedarf von 
über 1,5 GigaByte zu verwalten. 


Local View Tools 


Mit Hilfe dieser Werkzeuge kann direkt auf der Hardware des Entwicklers eine vor- 
übergehende SINIX-Entwicklungsversion erstellt und funktionell verifiziert wer- 
den (z.B. unter Zuhilfenahme eines Analysators zur Code-Überdeckung während 
des Funktionsstests). 


gTSIMX 


Ein grafischer Terminalsimulator, der an interaktive Anwendungen angeschlossen 
werden kann und diese dann automatisch mit einem SOLL-/IST-Vergleich zum Ab- 
lauf bringt. gTSIMX wird sowohl zum Test von Bedienoberflächen als auch zur Be- 
obachtung der Leistungsfähigkeit eingesetzt. 


ATIX 


Ein automatisches Testsystem, das etwa 20.000 Testfälle mit insgesamt mehr als 
drei Millionen LOCs (Lines of Source Code) verwaltet. ATIX bietet eine komforta- 
ble Bedienoberfläche, um Testfälle auszuwählen und Testergebnisse abzufragen. 
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PULS 


Ein Fehler-Management-System zur weltweiten Verwaltung aller Problemmeldun- 
gen während des Lebenszyklus eines Produkts. PULS stellt komfortable Recher- 
chemöglichkeiten und Trendübersichten zur Verfügung. 


ProTeln 


Eine Termindatenbank, die alle für ein Projekt relevanten Termine einschließlich 
notwendiger externer Zulieferungen verwaltet und Übersichten zur Terminüberwa- 
chung erstellt. 


Nach der Kundenfreigabe wird die Anzahl der Problemmeldungen zu einem Pro- 
dukt regelmäßig kontrolliert und im Detail analysiert. Die Testwerkzeuge werden 
entsprechend erweitert, so daß ein kontinuierlicher Qualitätsfortschritt sicherge- 
stellt ist. 


Testmethodik 
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Die Testmethodik bei der SINIX-Entwicklung ist gekennzeichnet durch einen 
mehrstufigen Prozeß, der dem jeweiligen Entwicklungsstand angepaßt wird. Alle 
Werkzeuge sind so konzipiert, daß sie weitgehend automatisch ablaufen. In der Re- 
gel prüfen sie das Testergebnis selbst und geben nur im Fehlerfall die für eine Dia- 
gnose notwendigen Informationen aus. Das Testsystem ATIX steuert den Start der 
einzelnen Werkzeuge, indem es den gewünschten Testbereich kennzeichnet und ih- 
ren Ablauf überwacht. Da ein Client/Server-Konzept verwendet wird, kann das 
Testsystem schnell und ohne großen Aufwand aktiviert werden. 


Ein Qualitätssicherungsplan für jedes Projekt legt fest, zu welchem Zeitpunkt im 
Projektverlauf ein bestimmter Test erfolgen soll. Die Leistungsfähigkeit der vorhan- 
denen Werkzeuge erfordert aus Gründen der Effizienz eine genau aufeinander abge- 
stimmte Planung. Diese muß möglichst redundanzfrei und trotzdem vollständig 
sein. So beginnt die Testphase eines Produkts letztendlich mit dem Test individuel- 
ler Funktionen und wächst sukzessive bis zum Test komplexer Hardware- und Soft- 
ware-Konfigurationen. Der Test komplexer Konfigurationen stellt insbesondere das 
Zusammenwirken der Produkte sicher - auch unter Grenzwertbedingungen und in 
einem heterogenen Netzverbund. 
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International standardisierte Testsuiten dienen dazu, einen objektiven Eindruck von 
der Qualität eines Produkts zu gewinnen. Verschiedene Testsuiten werden in unse- 
ren anerkannten Testumgebungen eingesetzt. Im SINIX-Umfeld sind die wichtig- 
sten: 


®e SVVS, die UNIX System V Validation Suite 


® VSX, die XPG-Testsuite zum Nachweis der X/Open-Konformität, der Voraus- 
setzung für den Erhalt des XPG-Warenzeichens 


® OSI-Testsuiten für Transportprotokolle im. LAN- und WAN-Bereich 
® offizielle Testsuiten für Compiler und OSF/Motif 


Als Ergänzung dazu dienen weitere eigene Testfolgen dem Nachweis der Konfor- 
mität zu anderen garantierten Schnittstellen wie dem SINIX API. Durch die Mitar- 
beit in internationalen Gremien, die sich mit den Themen Qualität und Konformität 
zu bestehenden Standards beschäftigen, forciert Siemens Nixdorf die Weiterent- 
wicklung solcher Testfolgen und setzt sich für deren Standardisierung ein. Ein Bei- 
spiel hierfür ist die OSI-Testfolge, die Siemens Nixdorf im Rahmen einer Aus- 
schreibung der Europäischen Gemeinschaft entwickelte. 


Um Leistungsvergleiche zwischen unseren Systemen und denen des Mitbewerbs 
anstellen zu können, bringt Siemens Nixdorf eine Vielzahl anerkannter Benchmarks 
(TPC, SPEC, AIM, Dhrystone, usw.) auf seinen Systemen zum Ablauf und veröf- 
fentlicht die gemessenen Werte über die entsprechenden Gremien. Falls ein Kunde 
für eine leistungskritische Anwendung eine optimale Ausnutzung seiner System- 
ressourcen erzielen möchte, kann er auf die Konfigurationsempfehlungen eines Per- 
formance-Handbuchs oder ergänzend dazu auf verschiedene Werkzeuge zur 
Leistungsanalyse (z.B. TRACEX) zurückgreifen. 


Um die Qualität und Leistungsfähigkeit einer Software-/Hardwarekonfiguration zu 
verifizieren, die speziell auf einen Kunden und seine spezifische dialogorientierte 
Anwendungssoftware zugeschnitten wurde, kann der grafische Terminalsimulator 
gTSIMX verwendet werden. So können Dialoge gesteuert und ein oder mehrere 
Anwender entweder auf real vorhandenen Terminals oder aber virtuellen Terminals 
simuliert werden. Eine derartige Simulation wurde von Siemens Nixdorf schon häu- 
fig als Dienstleistung beim Kunden für dessen spezielle Anwendungen durchge- 
führt. 
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Die Gesamtheit der von Siemens Nixdorf eingesetzten Test- und Kontrollwerkzeu- 
ge, ihre Weiterentwicklung sowie eine Testplanung, die auf Vollständigkeit zielt, 
garantieren zusammen die kontinuierlich verbesserte Qualität und eine ständig sin- 
kende Anzahl verbleibender Fehler im Verlauf eines Projekts. Die Statistiken, die 
von den verschiedenen Testwerkzeugen erstellt werden, werden vom Management 
dazu benutzt, Jahr für Jahr noch anspruchsvollere Qualitätsziele festzusetzen. 


SINIX-Dokumentation 
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Die hohe Qualität der Dokumentation ist eines der wesentlichen Merkmale von 
SINIX. Sowohl das SINIX-Betriebssystem als auch die vielen Software-Produkte, 
die auf SINIX aufsetzen, werden mit einer vollständigen Anwenderdokumentation 
ausgestattet. Die Handbücher werden im allgemeinen in deutscher und englischer 
Sprache produziert. In vielen Fällen werden sie jedoch auch in andere Sprachen 
übersetzt. Alle Dokumentationen sind einheitlich aufgebaut und weisen ein einheit- 
liches Corporate Design auf. 


Dokumentation wird bei Siemens Nixdorf von technischen Redakteuren, Experten 
für die Vermittlung technischer Information, in enger Zusammenarbeit mit der Soft- 
ware-Entwicklung erstellt. So wird gewährleistet, daß die Dokumentation folgende 
Anforderungen erfüllt: 


® Sie ist fachlich korrekt und vollständig, 

® optimal auf die jeweilige Zielgruppe ausgerichtet, 

® verständlich, 

® sowie termingerecht zur Lieferfreigabe eines Software-Produkts verfügbar. 


Um die fachliche Korrektheit und Vollständigkeit der Dokumentation sicherzustel- 
len, wird die Dokumentation einer sorgfältigen fachlichen Überprüfung unterzogen, 
an der Entwickler, Tester sowie Produkt- und Systemplanung beteiligt sind. Zusätz- 
lich wird die Dokumentation im Lektorat von speziell dafür ausgebildeten Mitarbei- 
tern dahingehend überprüft, ob sie verständlich und konsistent aufgebaut ist und der 
anvisierten Zielgruppe entspricht. 


Man Pages 
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Die hohe Qualität der SINIX-Dokumentation ist schon mehrmals durch eine objek- 
tive, externe Bewertung bestätigt worden. So wurde etwa die Dokumentation für 
eine Reihe von SINIX-Produkten in Rezensionen in der Fachpresse äußerst positiv 
beurteilt. Eine Reihe von Titeln der SINIX-Dokumentation wurde von namhaften 
Verlagen in ihr Programm übernommen. Darüber hinaus sind mehrere Titel der 
SINIX-Dokumentation bei internationalen Wettbewerben von der amerikanischen 
„Society for Technical Communication“ ausgezeichnet worden. 


Aufbau und Gliederung der SINIX-Dokumentation entspricht dem De-facto- 
UNIX-Standard. So kann sich jeder, der mit UNIX vertraut ist, schnell in der SI- 
NIX-Dokumentation zurechtfinden. Damit wird der Idee der offenen Systeme 
Rechnung getragen. Inhaltlich geht die Information jedoch weit über die des Stan- 
dard-UNIX hinaus. Die Beschreibungen der SINIX-Kommandos etwa werden 
durch zusätzliche Beispiele erweitert, um die Verständlichkeit und Anwender- 
freundlichkeit der SINIX-Dokumentation zu erhöhen. 


Zur Dokumentation des SINIX-Betriebssystems gehört auch das Handbuch Master 
Index, ein übergreifendes, vollständiges Gesamt-Stichwortverzeichnis für die we- 
sentlichen Handbücher des Dokumentationspakets. Es ermöglicht dem Benutzer, 
Informationen ungeachtet des großen Umfangs der SINIX-Dokumentation schnell 
aufzufinden. 


Die Dokumentation des Betriebssystems SINIX und seiner Aufsatzprodukte besteht 
nicht nur aus den traditionellen Handbüchern auf Papier. Dokumentation wird auch 
Online am Rechner zur Verfügung gestellt. Siemens Nixdorf bietet zudem neue 
Technologien wie Hypertext oder kontextsensitive Hilfe. 


SINIX unterstützt das Standard-UNIX Kommando man, das dem Anwender er- 
laubt, Online auf Informationen der Referenzhandbücher zugreifen zu können. In 
SINIX wird der Text dieser sogenannten Man Pages aus der gleichen Quelldatei wie 
die Referenzhandbücher erzeugt. Papierdokumentation und Online-Dokumentation 
sind damit einheitlich und vollständig. Siemens Nixdorf bietet auch zusätzliche 
Man Pages im Standardformat an, um Aufsatzprodukte zu unterstützen. 
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Online-Hilfe 


Ausblick 
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Neben den Man Pages stellt SINIX auch Online-Hilfen zur Verfügung. Dies ge- 
schieht in einigen Fällen über Fremdprodukte wie etwa OSF/Motif. In anderen Fäl- 
len wird die Online-Hilfe direkt von Siemens Nixdorf als Bestandteil eines eigenen 
Software-Produkts angeboten. Das Produkt SINIX/windows erweitert die Online- 
Hilfe um kontextsensitive Hilfe und hypertext-ähnliche Verknüpfungen. Kon- 
textsensitive Hilfe ermöglicht dem Anwender, Informationen über ein bestimmtes 
Objekt auf dem Bildschirm (z.B. eine Menüoption,) zu erhalten. Die hypertext-ähn- 
lichen Verbindungen erlauben dem Anwender, sich durch eine Reihe von Hilfetex- 
ten zu bewegen, indem er hervorgehobene Wörter auswählt. 


Siemens Nixdorf wird seine Anstrengungen fortsetzen, um sicherzustellen, daß die 
Dokumentation den effektiven Einsatz von SINIX-Systemen und SINIX-Software- 
Produkten erleichtert. Weiterhin werden hohe Qualitätsanforderungen an Papierdo- 
kumentation, Man Pages und Online-Hilfen gestellt und zusätzliche Techniken ge- 
testet werden, um dem Anwender Dokumentation zur Verfügung zu stellen. Zur 
Zeit ist die Präsentation der SINIX-Dokumentation auf CD-ROM mit einem 
Retrievalsystem und grafischer Bedienoberfläche in Vorbereitung. 
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Überblick 


Zukünftige Entwicklungen lassen sich nicht mit Sicherheit vorhersehen. Einige 
Dinge können wir jedoch schon sehen, denn wir wissen natürlich, um wie viele Jah- 
re die Forschung in den Bereichen Informatik und Computertechnik mittlerweile 
den bereits auf dem Markt befindlichen Systemen voraus ist. Die Forschungsarbeit 
in den Laboren gibt uns einen guten Einblick in die Möglichkeiten, die uns die Da- 
tenverarbeitung im kommerziellen Einsatz in Zukunft geben wird. Es ist naturge- 
mäß nur schwer vorherzusagen, welche dieser Technologien sich tatsächlich in die 
Praxis umsetzen lassen, und aufgrund welcher ökonomischen Gegebenheiten sie 
sich auf dem Markt durchsetzen werden. 


Bei allen Planungen muß man also die Entwicklungsmöglichkeiten der Zukunft 
miteinkalkulieren. Drei technologische Bereiche werden unserer Meinung nach in 
der kommerziellen Datenverarbeitung eine entscheidende Rolle spielen: kooperati- 
ve Datenverarbeitung, objektorientierte Verarbeitung und Multimedia-Fähigkeit. In 
diesem Kapitel erhalten Sie einen Überblick über diese drei Bereiche. 


209 


10 Zukünftige Entwicklungen 


Kooperative Datenverarbeitung 


Der hier verwendete Begriff der kooperativen Datenverarbeitung bezieht sich auf 
drei Ebenen: die Bediener- oder Anwendungsebene, die Betriebssystemebene und 
die Hardwareebene. Auf Bedienerebene wird die weite Verbreitung von verteilten 
Anwendungen dazu führen, daß unterschiedliche Prozesse (Clients und Server) auf 
verschiedenen Rechnern miteinander kooperieren. Auf der Betriebssystemebene 
wird es die sogenannte Mikrokerneltechnologie ermöglichen, daß die unterschied- 
lichen Betriebssysteme in eine Reihe von kooperierenden Prozessen aufgeteilt wer- 
den können. Auf Hardwareebene werden mehrere Prozessoren in einem Rechner in 
ganz unterschiedlichen Konfigurationen kooperativ miteinander arbeiten können, 
indem Prozesse auf Betriebssystem- und Anwendungsebene parallel bedient wer- 
den. 


Bedienerebene 


Betriebssystemebene Mikrokernelbasierte 


Betriebssysteme 


Hardwareebene 
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Abbildung 10-1: Die kooperative Datenverarbeitung umfaßt drei verschiedene technologische Gebiete auf drei 
verschiedenen Ebenen. 


Kooperative Datenverarbeitung bietet deutliche Vorteile, die im folgenden kurz ex- 
emplarisch dargestellt werden: 
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® Die kooperative Datenverarbeitung erlaubt die gemeinsame Nutzung von Res- 
sourcen und trägt damit zu einer erheblichen Kostensenkung bei. Wenn z.B. die 
Leerlaufzeiten eines Prozessors vermindert werden können, kann man ohne 
Mehraufwand und Kosten ansonsten vergeudete Zeit einsparen. 


® Durch die kooperative Datenverarbeitung kann die Leistungsfähigkeit von 
Computern kostengünstig durch einfaches Hinzufügen von vorgefertigten und 
damit billigen Bauteilen in Modularbauweise erhöht werden. Man muß kein 
weiteres großes und teures System anschaffen, sondern kann schrittweise ko- 
stengünstige Bauteile in das System einfügen: z.B. kann man eine weitere Pro- 
zessorbaugruppe in einen vorhandenen Rechner einbauen oder einen zusätzli- 
chen kleineren Rechner in ein Netzwerk einhängen. 


® Die kooperative Datenverarbeitung erleichtert die Teamarbeit und die Arbeit an 
gemeinsamen Projekten. Arbeitsgruppen können gemeinsame Ressourcen ein- 
setzen, z.B. auf gemeinsam genutzte Dateien zugreifen, Echtzeitkommunikation 
betreiben, sich Computerarbeitsplätze teilen usw. 


® Die kooperative Datenverarbeitung steigert mit geringen Kosten die Verfügbar- 
keit, indem Dienstleistungen mehrfach angeboten werden. Wenn ein Anbieter 
von Dienstleistungen ausfällt, kann ein anderer dafür schnell einspringen, ohne 
daß dadurch der Betrieb gestört oder ein Anwender etwas bemerken würde. 
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Technologien auf Anwendungsebene: Verteilte Verarbeitung 


Siemens Nixdorf geht davon aus, daß die kooperative Datenverarbeitung auf An- 
wenderebene vor allem auf der Grundlage von DCE entwickelt werden wird, da 
DCE von den meisten Computerherstellern und Softwarehäusern an ihre jeweiligen 
Systeme angepaßt wurde. DCE ist damit zum De-facto-Industriestandard geworden 
und X/Open ist dabei, DCE zum Common-Applications-Environment-Standard 
(CAE) zu erheben. 


Vorteile der kooperativen Datenverarbeitung für den Anwender 
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Die wichtigsten Vorteile der kooperativen Datenverarbeitung auf Anwenderebene 
mit DCE können folgendemaßen skizziert werden: 


® nicht sichtbare örtliche Verteilung 
® Verfügbarkeit 

® Anpassungsfähigkeit 

® Integrierte Sicherheit 


® Einfache Bedienung 


Nicht sichtbare örtliche Verteilung 


Den Benutzern von DCE bleibt der Standort eines Rechners, der bestimmte Dienst- 
leistungen bereitstellt, verborgen. Durch die besonderen Bindemechanismen von 
DCE und dem Name-Service bleiben die DCE-Dienste in hohem Maße ortsunab- 
hängig. 


Verfügbarkeit 


Verteilte Systeme müssen unabhängig von Netzunterbrechungen oder Fehlern auf 
fernen Rechnern arbeiten können. DCE unterstützt zur Erhöhung der Verfügbarkeit 
die Mehrfachhaltung des Cell-Directory-Servers und des Security-Servers. Durch 
eine Mehrfachhaltung von Anwendungsservern kann eine zusätzliche Steigerung in 
der Verfügbarkeit erreicht werden. 
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Anpassungsfähigkeit 


Netzwerke der Zukunft werden um ein Vielfaches größer und geographisch weit- 
läufiger sein als heute. Folgendes Szenario ist keine Utopie: Fast alle PCs verfügen 
über eine Netzanbindung und Metropolitan Area Networks (MAN) oder Wide Area 
Networks (WAN) sind weit verbreitet. Hunderte von parallel gehaltenen Servern 
können Tausenden von Clients ihre Dienste anbieten. Einige Server müssen inner- 
halb kürzester Zeit vielen Hundert Clients ihre Dienste zur Verfügung stellen, und 
einige Clients müssen in ebenso kurzer Zeit mit Hunderten von Servern Kontakt 
aufnehmen. Die einzelnen Komponenten von DCE sind so angelegt, daß sie sich 
ohne Schwierigkeiten großen Netzwerken anpassen können, ohne daß dabei ein 
Verlust an Leistung, Zuverlässigkeit oder Flexibilität zu befürchten wäre. Da es kein 
Kunde schätzt, wenn sich herausstellt, daß ein Computersystem gleichsam über 
Nacht zu klein geworden ist und man nun von vorne anfangen muß, ist es wichtig, 
daß man die Möglichkeit hat, immer neue Maschinen auch von unterschiedlichen 
Herstellern dazuzukaufen, diese in vorhandene Netze einzubinden, Netzwerksyste- 
me zu bilden, immer umfangreichere Anwendungen und Datenbanken einzusetzen, 
ohne dabei etwas wegwerfen oder neu aufbauen zu müssen. DCE garantiert diese 
Erweiterungsfähigkeit. 


Sicherheit 


Eine der wichtigsten Voraussetzungen für verteilte Verarbeitung ist die Sicherheit. 
In DCE sind die neusten Forschungsergebnisse (Identifizierung und Autorisierung) 
eingeflossen, um ein Höchstmaß an Sicherheit zu gewährleisten. 


Einfache Bedienung 


DCE ist einfach zu bedienen, da sich der Anwender fast um nichts kümmern muß. 
Durch seinen Name-Service erreicht es DCE, daß es keine Rolle spielt, auf welchem 
Netzrechner eine bestimmte Ressource verfügbar ist, denn für den Anwender spielt 
es keine Rolle, auf welchem Rechner die Daten liegen und welcher Rechner diese 
gerade bearbeitet. Kein Anwender möchte sich mit dem komplexen Aufbau des zu- 
grundeliegenden physikalischen Netzes befassen müssen, auch die komplizierten 
Protokolle und die ungeheure Rechenleistung interessieren kaum. Anwender möch- 
ten ohne Aufwand an ihre Daten kommen, sie wollen dafür keine komplizierten und 
schwer zu handhabenden Prozeduren verwenden müssen. 
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Die Mehrfachhaltung der Ressourcen in DCE ist für den Anwender nicht sichtbar. 
Eine beliebige Anzahl von Anwendern kann dieselbe Ressource anfordern und kei- 
ner der Anwender wird bemerken, daß er nicht der einzige ist, der dieselbe Dienst- 
leistung in Anspruch nimmt. 


In einem korrekt aufgebauten System, das auf DCE beruht, werden auftretende Feh- 
ler durch Mehrfachhaltung der Ressourcen keinen Schaden anrichten und nicht in 
Erscheinung treten. Ein auftretendes Problem eines Prozesses, eines Rechners oder 
der Netzwerkverbindung kann also einen Anwender nicht in der Fortführung seiner 
Arbeit behindern. 


Siemens Nixdorf fördert die verteilte Verarbeitung 
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Siemens Nixdorf spielt eine wesentliche Rolle bei der Entwicklung und Vermark- 
tung der verteilten Verarbeitung in Form des Softwareproduktes Distributed Com- 
puting Environment (DCE) der Open Software Foundation (OSF). Siemens 
Nixdorf ist einer der Mitbegründer und Sponsoren der Open Software Foundation. 
Das Produkt DIR-X von Siemens Nixdorf wurde von OSF als Grundlage des DCE- 
basierten Global Directory Service ausgewählt. OSF hat Siemens Nixdorf als Lie- 
feranten der Referenzimplementierung von DCE auf UNIX SVR4 bestimmt. 
Siemens Nixdorf und die UNIX System Laboratories (USL) sind in einem 
Kooperationsvertrag übereingekommen, daß USL die DCE-Referenzimplementie- 
rung verwendet und im expandierenden UNIX-SVR4-Markt unterstützt. Siemens 
Nixdorf wird auch weiterhin DCE aktiv fördern und daran arbeiten, die Anzahl der 
mit DCE verfügbaren Anwendungen zu erhöhen und damit zur weiteren schnellen 
Verbreitung der verteilten Verarbeitung auf Anwenderebene erheblich beizutragen. 
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Neue Technologien der Betriebssysteme 


Die Betriebssysteme der neuen Generation in Mikrokerneltechnologie teilen die lo- 
gische Funktionalität des Kernels eines traditionellen Betriebssystems in funktiona- 
le Objekte. Diese funktionalen Objekte bilden unabhängige, miteinander kommuni- 
zierende Einheiten. Ein gegenüber herkömmlichen Systemen vergleichbar kleiner 
Teil des Betriebssystemkerns, der sogenannte Mikrokernel, enthält eine Sammlung 
von grundlegenden Mechanismen, die den Betrieb eines Betriebssystems ermögli- 
chen. Weitergehende Funktionen, die für besondere Arbeitsumgebungen in einem 
Betriebssystem benötigt werden, können dann außerhalb des Mikrokernels reali- 
siert werden; dadurch bleiben sie vom Mikrokernel unabhängig. Der Mikrokernel 
bildet die einzig mögliche Schnittstelle zur Hardware. Seine Strukturierung in hard- 
wareabhängige und hardwareunabhängige Teile macht seine hohe Modularisierung 
und Erweiterungsfähigkeit und damit einfache Portierbarkeit deutlich. 


Werden weitere Funktionselemente außerhalb des Mikrokernels benötigt, um eine 
komplexe Betriebssystemumgebung aufzubauen (z.B. eine SINIX-Umgebung), so 
werden diese in Form von Servern bereitgestellt. Die Server repräsentieren dann 
funktionale Objekte, die ihre Dienste in Form von Client-Server-Verbindungen an- 
bieten. Auf diese Weise wird der volle Funktionsumfang eines Betriebssystems er- 
reicht, indem einzelne Elemente zusammengefügt werden. Die einzelnen Kompo- 
nenten sind die Module, aus denen dann ein ganzes System aufgebaut wird. Man 
spricht in diesem Zusammenhang von einem skalierbaren System. 


Betriebssysteme in Mikrokerneltechnologie unterscheiden sich von traditionellen 
Betriebssystemen vor allen Dingen in der Speicherverwaltung. Die einzelnen Spei- 
cherregionen werden in sogenannte Speicherobjekte aufgeteilt. Die Verwaltung die- 
ser Speicherobjekte im Hauptspeicher wird vom Mikrokernel übernommen. Ein 
spezieller Speichermanager (Speicher-Server) ist für die nicht speicherresidenten 
Abbildungen (z.B. auf der Festplatte) zuständig. Der Mikrokernel arbeitet unabhän- 
gig von den sekundären Abbildungen in den Speicherregionen, für die ausschließ- 
lich der Speichermanager zuständig ist. Auf diese Weise können z.B. verschiedene 
Paging-Algorithmen, Shared-Memory über Rechnergrenzen hinweg und Mechanis- 
men zur besseren Fehlertolerierung in den Mikrokernel und in Anwenderprogram- 
me eingebaut werden, ohne daß dies nach außen sichtbar wird. 
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Aus den oben genannten Gründen lassen sich die Vorteile der Mikrokerneltechno- 
logie wie folgt zusammenfassen: 


Wegen der einfachen Portierbarkeit der Mikrokernel auf andere Prozessor- oder 
Speicherarchitekturen wird auch der Umstieg auf neue Hardwarearchitekturen 
erleichtert, d.h. besseres Time-to-Market. 


Die eingebaute Fähigkeit zur Parallelverarbeitung ermöglicht eine bessere Aus- 
nutzung von Multiprozessorrechnern, als dies bisher möglich war. Dies ermög- 
licht auch den Einsatz von massiv parallelen Architekturen. 


Die interne Strukturierung (also Unterteilung in Funktionsgruppen) in unabhän- 
gige, autonom arbeitende Einheiten (Server) bietet die Möglichkeit, ein System 
rasch durch neue Funktionen zu erweitern und damit einfach und flexibel zu- 
künftige Anforderungen erfüllen zu können. 


Es ist möglich, auf einem Rechner mehrere Versionen des gleichen Betriebssy- 
stems ablaufen zu lassen, indem einfach die jeweiligen Server geladen werden. 
Der Kunde kann so eventuell auftretenden Kompatibilitätsproblemen mit älte- 
ren Anwendungen beim Übergang zu einer neuen Betriebssystemversion aus 
dem Weg gehen und den Aufwand für eine Anpassung der Anwendung sparen. 


Auf einem Rechner können die verschiedensten Betriebssysteme nebeneinander 
betrieben werden, z.B. SINIX, MS-DOS, MS-Windows, OS/2 usw. Die Kunden 
erhalten dadurch eine größere Freiheit bei der Auswahl der Anwendungen, in 
die sie investieren. 


Indem einzelne Prozesse in Clients und Server aufgeteilt werden können, erhöht 
sich u.a. die Zuverlässigkeit und Stabilität des gesamten Systems beträchtlich. 
Die Ausfallzeit eines Systems kann erheblich verringert werden, da Server 
mehrfach vorhanden sein können, ohne daß dies vom Client bemerkt wird. 


Die derzeit verbreitetsten Mikrokernelsysteme sind OSF/1 MK von OSF (basierend 
auf dem Betriebssystem Mach der Carnegie Mellon University), das System 
CHORUS von CHORUS Systemes und Windows NT von Microsoft. 
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Einem Server (Management eines SINIX-Prozesses, des Dateisystems usw.) kann 
man Betriebssystemaufgaben (z.B. SINIX) übertragen. Außerdem geht man heute 
dazu über, Server in sogenannte generische und spezifische Server zu unterteilen. 
Innerhalb eines generischen Servers werden Aufgaben von allgemeinem Interesse 
ausgeführt, z.B. Name-Server, Identifikations-Server oder Datei-Server. Innerhalb 
eines spezifischen Servers werden Aufgaben erledigt, die zu einer Betriebssystem- 
umgebung (z.B. SINIX-, Windows-, DOS-, und OS2-Server) gehören. Damit wird 
ein hoher Grad an Flexibilität erreicht. Skalierbare Systeme können auf diese Weise 
aus einem Mikrokernel und aus verschiedenen, vom Server bereitgehaltenen Funk- 
tionen erstellt werden. Durch Verwendung geeigneter Mechanismen ist es deshalb 
möglich, Programme, die für ein bestimmtes Betriebssystem (z.B. SINIX) entwik- 
kelt wurden, durch einen Mikrokernel auf einem entsprechenden Betriebssystem- 
server binärkompatibel ausführen zu lassen. Die einzige Voraussetzung dafür ist, 
daß das Programm für den verwendeten Prozessortyp compiliert wurde. 


Mikrokerneltechnologie bei Siemens Nixdorf 


Siemens Nixdorf ist sehr daran interessiert, die Mikrokerneltechnologie zu fördern. 
Dies bedeutet nicht nur die Förderung der theoretischen Forschungsarbeit, sondern 
auch die praktische und experimentelle Arbeit. Eine Forschungsgruppe von Sie- 
mens Nixdorf hat z.B. die Funktionalität von UNIX SVR4 (SINIX) in Form eines 
Servers auf das OSF/l MK-System übertragen. Gleichzeitig wurde die technische 
Durchführbarkeit der Portierung dieses Servers auf Windows NT untersucht. Ge- 
genwärtig wird der Server von Siemens Nixdorf als Teil eines Forschungsprojekts 
der Europäischen Gemeinschaft auf das System CHORUS portiert. Diese Arbeit 
dient dazu, den technologischen Vorsprung von Siemens Nixdorf auf dem Gebiet 
der Entwicklung, des Tests, der Pflege und des Einsatzes solcher Systeme zu de- 
monstrieren. Die SINIX-Entwicklung fördert diese weltumspannenden Aktivitäten 
und trägt stets dafür Sorge, das nötige Wissenspotential zur Verfügung zu haben. 
Ziel ist es, diese neuen Technologien in die Weiterentwicklung von SINIX einflie- 
Ben zu lassen. 
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Ein Betriebssystem bildet die Brücke zwischen den Anwendungen und der zugrun- 
deliegenden Hardware. Deshalb muß ein Betriebssystem auch schnell an die sich 
verändernden Computerarchitekturen anpaßbar sein. Diese Anpassungsfähigkeit 
führt zu einer Kostensenkung für Entwicklung, Wartung und Service und ermög- 
licht eine schnellere Verfügbarkeit neuer Technologien, z.B. auf dem Gebiet der 
Prozessortechnik. Für den Kunden ist es wünschenswert, daß die verschiedenen 
Rechnerarchitekturen, seien es Einzelprozessorrechner, Multiprozessorrechner, 
massiv parallele Systeme oder über Netzwerke gekoppelte Betriebssysteme bedient 
werden können. Aus diesem Grund gibt es die Forderung nach sogenannten skalier- 
baren, den Kundenanforderungen anpaßbare Systeme. Man erreicht damit System- 
strukturen, aus deren Bestandteilen ein komplettes System gebildet werden kann, 
das dann unter gegebenen Voraussetzungen erstellt, installiert und angepaßt wird. 
Damit ist gewährleistet, daß der Kunde immer über ein an die technischen Neuerun- 
gen angepaßtes System verfügt. Vorhandene langfristige Investitionen bleiben da- 
mit über einen langen Zeitraum gesichert, vorhandene Anwendungen können 
schneller und flexibler an neue Gegebenheiten angepaßt werden. 


Siemens Nixdorf ist stets darum bemüht, seinen Kunden immer den neusten Stand 
der Technik zu liefern, sobald dies wirtschaftlich vertretbar ist. Unsere Kunden ha- 
ben in Anwendungen investiert, die auf Aussagen im SINIX API beruhen. Siemens 
Nixdorf wird das SINIX API auch für die verschiedenen Mikrokernelsysteme un- 
terstützen. Das erlaubt unseren Kunden, neue Computerarchitekturen zu nutzen, 
ohne dabei schon getätigte Investitionen in SINIX-Systeme zu verlieren. Da mikro- 
kernelbasierte SINIX-Systeme das SINIX API anbieten werden, brauchen schon 
existierende Anwendungen nicht umgeschrieben zu werden, damit diese mit der 
neuen Architektur und mit Anwendungen, die speziell für eine Mikrokernelarchi- 
tektur neu entwickelt wurden, zusammen ablauffähig sind. 


Modularisierte Komponenten eines Mikrokernels können zu einem späteren Zeit- 
punkt ohne weiteres durch neuere ersetzt werden, damit neuere Rechnerarchitektu- 
ren und Server unterstützt werden. Weitere Module können hinzugefügt werden, um 
zusätzlich zum SINIX-Grundsystem andere Systemumgebungen anbieten zu Kön- 
nen, beispielsweise die Unterstützung von Windows zusätzlich zu SINIX oder von 
herstellerspezifischen Systemen. Es folgt ein kurzer Überblick über die Forschungs- 
tätigkeit von Siemens Nixdorf auf dem Gebiet der Mikrokerneltechnologie. 
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Abbildung 10-2: Die Funktionen eines herkömmlichen Betriebssystems, die nicht in den Mikrokernel integriert 
sind, können auf verschiedene Prozessoren verteilt werden. Das Beispiel zeigt die Konfiguration eines CHORUS- 
Systems mit drei Prozessoren, die über Netz oder Bus miteinander verbunden sein können. 


Mach 3.0 


Siemens Nixdorf hat einen SINIX-Server entwickelt, der Mach 3.0 unterstützt. Die- 
ser Server ist modularer Systembestandteil von Mach 3.0 und arbeitet im Usermo- 
dus des Prozessors als Mach-Anwendung. Dieses Subsystem ist 100% binärkompa- 
tibel für existierende SINIX-Anwendungen. Das zeigt deutlich, wie die 
Mikrokernelarchitektur die Erwartungen in Bezug auf Kompatibilität erfüllt. Sie- 
mens Nixdorf hat hiermit ein SINIX-Subsystem für Mach 3.0 verfügbar, das im In- 
teresse der Siemens-Nixdorf-Kunden neue Wege für die Weiterentwicklung der Be- 
triebssysteme in der Mach-3.0-Welt eröffnet. Die aus dieser Entwicklung 
gewonnene Erfahrung bildet eine hervorragende Basis für die Weiterentwicklung 
von Mikrokernelsystemen. 
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Das OSF Forschungsinstitut leistet hier weiterführende Arbeit. Ausgehend von ei- 
nem Mach-3.0-Mikrokernel wurde OSF/L-AD entwickelt. Diese Arbeit wurde von 
Siemens Nixdorf begutachtet. Sobald diese Technologie stabil und für den kommer- 
ziellen Einsatz verfügbar ist, können wir eine SINIX-basierte Implementation ent- 
wickeln. 


Chorus 


Zusammen mit den UNIX System Laboratories und anderen europäischen Firmen 
aus dem Bereich Datenverarbeitung nimmt Siemens Nixdorf am Projekt Ouverture 
teil. Dieses anspruchsvolle Entwicklungsprojekt ist dazu angelegt, die ES/MP-Ver- 
sion des UNIX-Betriebssystems von USL auf den Chorus-Mikrokernel zu verteilen. 
Sobald dieses Projekt erfolgreich abgeschlossen ist, wird es in Zukunft möglich 
sein, SINIX-Anwendungen auf verteilten und fehlertoleranten Systemen ablaufen 
zu lassen. 


Anwendungen 


UNIX SVRA DOS Os/2 


Mach-Mikrokernel 


Abbildung 10-3: Man kann verschiedene Betriebssystem-Server (man spricht auch von „Personalities“) auf einen 
Mikrokernel aufsetzen. Im Rahmen eines Forschungsprojekts wurde UNIX SVR4 in einen Mach-Mikrokernel ein- 
gebunden. 
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Neue Technologien auf dem Hardwaresektor 


Als treibende Kraft hinter den Systementwicklungen steht der Wunsch nach immer 
größerer Leistung. In den letzten Jahren konnten erstaunliche Entwicklungssprünge 
bei der Entwicklung neuer Prozessortechnologien verzeichnet werden. Zudem wer- 
den Leistungssteigerungen nicht allein dadurch erzielt, daß bessere Prozessoren 
entwickelt werden, sondern auch durch die Kombination von mehreren Prozessoren 
in einem Rechner. Theoretisch könnte man, wenn man nur eine genügend große 
Zahl von Prozessoren verwendete, die Rechenleistung schier ins Unermeßliche stei- 
gern. Leider sieht die Wirklichkeit anders aus, denn man erreicht ab einer gewissen 
Größe Leistungsgrenzen, die durch die Rechnerarchitektur und das verwendete Be- 
triebssystem vorgegeben sind. Beläßt man die Zahl der Prozessoren aber in einem 
durch das System vorgegeben Rahmen, kann man mit einem Multiprozessorsystem 
durch einfaches Hinzufügen von neuen Prozessoren erhebliche Leistungssteigerun- 
gen erreichen. Trotz steigender Ansprüche braucht man nicht auf ein anderes Com- 
putersystem umzusteigen. 


Computersysteme mit mehreren parallel betriebenen Prozessoren kann man in zwei 
Gruppen unterteilen: SIMD- (single instruction multiple data) und MIMD-Systeme 
(multiple instruction multiple data). SIMD beschreibt eine Architektur, in der alle 
vorhandenen Prozessoren gleichzeitig die gleichen Operationen für unterschiedli- 
che Daten ausführen. Dieses Verfahren wird vor allem im wissenschaftlichen Be- 
reich angewandt, wo komplizierte Gleichungen mit großen Datenmengen gelöst 
werden müssen. MIMD beschreibt eine Architektur, in der die einzelnen Prozesso- 
ren unterschiedliche Programme ausführen. Dieses Verfahren ist im allgemeinen 
besser im kommerziellen Bereich einsetzbar. Bei der MIMD-Architektur kann man 
zwei Varianten unterscheiden: Es gibt Systeme, die Distributed Memory (verteilte 
Speicher) und solche, die Common Memory (gemeinsam nutzbare Speicher) ver- 
wenden. Distributed Memory bedeutet, daß den einzelnen Prozessoren eigene Spei- 
cherbereiche zugeordnet sind und Daten untereinander über extrem schnelle Ver- 
bindungen (sog. Interconnects) austauschen, während Common Memory bedeutet, 
daß alle vorhandenen Prozessoren auf einen einzigen gemeinsamen Speicherbe- 
reich zugreifen. Die meisten bisherigen UNIX-Systeme auf Multiprozessorbasis 
sind solche mit Common-Memory-Architektur. 


221 


10 Zukünftige Entwicklungen 


222 


Sobald in einem Multiprozessorsystem viele Prozessoren gleichzeitig über einen 
gemeinsamen Bus auf Daten zugreifen wollen, wird der Bus schnell zu einem Eng- 
paß. Deshalb wird in Multiprozessorsystemen mit Hochleistungs-Cache-Speichern 
gearbeitet, damit die Häufigkeit der Zugriffe auf den Hauptspeicher drastisch redu- 
ziert werden können. So kann man die Anzahl der Datenzugriffe einer zentralen Re- 
cheneinheit auf den Speicher normalerweise auf wenige Prozent der ursprünglichen 
Menge verringern. Für die Datenkonsistenz muß dann die Hardware Sorge tragen. 


Der große Vorteil des Common Memory liegt vor allem darin, daß man nicht erst 
eigene Programme für diese Art der Speicherverwaltung schreiben muß. Jedes An- 
wendungsprogramm, das für ein Monoprozessorsystem entwickelt wurde, ist 
grundsätzlich auch auf einem Multiprozessorsystem ablauffähig. Ein Programm, 
das für ein Monoprozessorsystem entwickelt wurde, ist auf einem System mit 
Distributed Memory ohne Probleme ablauffähig. Unterschiede ergeben sich bei ei- 
nem Programm, das mehrere Verarbeitungseinheiten nutzt (Multithreading), die in 
einem gemeinsamen Speicher Daten halten und sich über Semaphore synchronisie- 
ren. Solche Anwendungen müssen an Stelle von einfachen Speicherzugriffen Mel- 
dungen an die anderen Verarbeitungseinheiten schicken. 
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Kleine Multiprozessorsysteme 


Wenn man von kleinen Multiprozessorsystemen spricht, meint man Systeme in ei- 
ner Größenordnung von zwei bis 20 oder 30 Prozessoren. Die Produktpalette von 
Siemens Nixdorf umfaßt derzeit zwei kleine Multiprozessorsysteme, die CISC-Li- 
nie mit Intel-Prozessor und die MIPS-Linie mit RISC-Prozessor. In den folgenden 
Abschnitten werden die kleinen Multiprozessorsysteme näher dargestellt. 


Symmetrische Multiprozessorsysteme 


Ein erfahrenes Entwicklungsteam hat das Betriebssystem SINIX so erweitert, daß 
es die volle Leistungsfähigkeit von Multiprozessorsystemen nutzen kann. Es han- 
delt sich dabei um symmetrische Multiprozessorsysteme. Jeder Prozessor kann ei- 
nen beliebigen Prozeß ausführen, es gibt keinen Prozessor für besondere Aufgaben. 
Dies gilt sowohl für die Software als auch für die Hardware. Ein gutes Beispiel für 
dieses Verfahren ist die Verteilung der Interrupts. Interrupts sind Unterbrechungen 
durch Hardwaresignale, die z.B. den Abschluß eines Datentransfers mitteilen. 


In einem symmetrischen Multiprozessorsystem kann jeder Prozessor beliebige In- 
terrupts bearbeiten. Auch in einem SINIX-Multiprozessorsystem kann jeder Pro- 
zessor die Interrupts der Hardwareuhr bedienen und so die Zeitscheiben für alle Pro- 
zesse auf dem neusten Stand halten. Die gleichmäßige Verteilung der Interrupts 
wird nach der Priorität der einzelnen Prozesse eines Prozessors vorgenommen. 
Wird einem Prozeß vom Betriebssystem eine höhere Priorität zugewiesen, wird der 
betroffene Prozessor dadurch seltener durch Hardwareinterrupts unterbrochen. Der 
Vorteil dieser Verteilung liegt in einer, durch Interrupts verursachten gleichmäßigen 
Auslastung der Prozessoren. Wäre nur ein Prozessor für alle Interrupts zuständig, 
könnte es eher zu Wartesituationen bei der Interruptbehandlung kommen. Die Pro- 
zesse in den anderen Prozessoren, die auf Interrupts warten, werden dardurch ver- 
zögert. Dadurch würde auch die gesamte Leistung des Rechners erheblich absinken, 
obwohl bei anderen Prozessoren noch erhebliche Ressourcen verfügbar wären. 


Solche Systeme arbeiten sogar in der Boot-Phase voll symmetrisch, denn das Sy- 
stem kann mit einem beliebigen Prozessor hochgefahren werden. Im Fehlerfall 
braucht keine der Prozessorbaugruppen ausgetauscht zu werden, da der Rechner 
einfach auf den nächsten verfügbaren Prozessor umschaltet und das Betriebssystem 
dann hochfährt. Diese Aufgabe wird von einer besonderen Baugruppe für Diagno- 
sezwecke (SCED-Board) erledigt, die im Bedarfsfall Befehle an Prozessorbaugrup- 
pen senden kann. Diese Befehle können Prozessoren auch dazu einsetzen, andere 
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Prozessorbaugruppen ab- oder zuzuschalten. Man verwendet dazu den Kernel-De- 
bugger. Im Fall eines Defekts oder eines Testlaufs kann ein betroffener Prozessor 
alle anderen Prozessoren anhalten und sich mit Hilfe des Debuggers auf der Konso- 
le melden. Der Kernel-Debugger zeigt dann den aktuellen Zustand des betroffenen 
Prozessors an, damit man schnell die Probleme isolieren kann, die zu der sogenann- 
ten Race-Condition (Lauffehler; eine Situation, in der Prozessoren gegenseitig Da- 
ten zerstören) geführt haben. 


Um SINIX an ein Multiprozessorsystem anzupassen, wurde der Kernel des Be- 
triebssystems für den Parallelbetrieb ausgelegt, damit mehrere Prozessoren gleich- 
zeitig Kernelroutinen ausführen können. Obwohl ein einzelner Anwenderprozeß zu 
einer Zeit nur auf einem Prozessor ablaufen kann, können andere Anwenderprozes- 
se gleichzeitig auf andere Prozessoren ablaufen. Die einzelnen Prozesse stören sich 
gegenseitig nicht, da ihre Anwenderdaten voneinander unabhängig sind und sich 
immer in unterschiedlichen Speicherregionen befinden. Trotzdem verwenden alle 
Prozesse gemeinsam Kernelroutinen, die ihrerseits gemeinsam Daten nutzen. Aus 
diesem Grund muß der Kernel auf allen Prozessoren gleichzeitig ablauffähig (d.h. 
multiprozessorfähig) sein. 


Wenn zwei Prozessoren versuchen, zur gleichen Zeit auf einen bestimmten Spei- 
cherplatz zu schreiben, müssen durch einen speziellen Sperrmechanismus (engl. 
Lock) die Zugriffe synchronisiert werden, um Inkonsistenzen zu vermeiden. Bevor 
ein Prozessor Systemdaten verändern darf, z.B. Vergabe einer neuen Prozeßnum- 
mer, muß dieser Sperrmechanismus in Gang gesetzt werden. Ist eine Sperre gesetzt, 
muß der Prozessor warten. In einem Multiprozessorsystem kann der Prozessor wäh- 
rend dieser Wartezeit nichts anderes tun, als die gewünschte Sperre anzufordern und 
ständig abzufragen und zu warten, bis sie frei geworden ist. Erst dann ist der Zugriff 
auf den Speicherplatz erlaubt. 


Bei der Entwicklung von parallelen SINIX-Systemen wurden die soeben beschrie- 
benen Probleme außergewöhnlich gut gelöst. Die Zentralbereiche des Kernels, wie 
z.B. Verwaltung des virtuellen Speichers oder Dateisystemroutinen, zeigen prak- 
tisch keine durch Kollisionen bedingte Stillstandsituationen. Dies wird durch die 
Tatsache belegt, daß die Leistung eines Zwei-Prozessorsystems bei den meisten An- 
wendungen 1,8-mal über der eines Monoprozessorsystems liegt. Das ist ein ein- 
drucksvolles Ergebnis. 
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Massiv Parallele Systeme 


Symmetrische Multiprozessorarchitekturen sind auf Systeme mit ca. 20 bis 30 Pro- 
zessoren beschränkt. Danach bringt eine höhere Anzahl von Prozessoren keine si- 
gnifikante Leistungssteigerung mehr, es sind sogar Leistungsminderungen möglich 
(Überlastung des Datenbus zum Hauptspeicher, Simultantreffer unter den Caches, 
Verfügbarkeit, usw.). Aus diesem Grund wird an neuen Lösungen gearbeitet. Mas- 
siv parallele Systeme sind große Systeme, die aus vielen preisgünstigen Mikropro- 
zessoren bestehen. Solche Systeme binden viele Mikroprozessoren durch neuartige 
Kommunikationsmechanismen aneinander, um die Arbeitsbelastung des Systems 
unter den verfügbaren Prozessoren aufzuteilen. Die Anzahl der Prozessoren kann 
theoretisch in die Tausende gehen. 


Um die Vorteile dieser neuen Computersysteme voll und ganz nutzen zu können, 
wird Betriebssystem-Software nötig, die in der Lage ist, die Systemressourcen zu 
verwalten und zu koordinieren. Bedeutende Änderungen des Betriebssystems sind 
erforderlich, um die zugrundeliegende Rechnerarchitektur zu unterstützen. Mikro- 
kernelbasierte Betriebssysteme stellen einen weitaus flexibleren Ausgangspunkt für 
die Entwicklung eines modularen Betriebssystems dar, das entsprechend der Anfor- 
derungen dieser Hardware-Plattformen konfiguriert werden kann. 


Massiv parallele Rechner sind derzeit ein wichtiges Thema in Forschung und Ent- 
wicklung. Sie werden von einigen Herstellern auch schon auf dem kommerziellen 
Markt angeboten. Diese Rechner bieten den Vorteil flexibler Abstufung aller Hard- 
ware-Elemente, so daß eine auf die unterschiedlichsten Anwendungsfälle zuge- 
schnittene Konfiguration zur Verfügung gestellt werden kann, die durch Hinzufü- 
gen zusätzlicher Prozessoren noch erweiterbar ist. 


Es gibt massiv parallele Computer mit einfachem Netzwerk, z.B. LANs. Für An- 
wendungen ist die Verteilung darin direkt sichtbar. Ohne großen Anpassungsauf- 
wand können bereits bestehende Anwendungen aus diesem Typ so gut wie keine 
Vorteile ziehen. Vorteilhaft ist jedoch ein anderer Typ massiv paralleler Systeme, 
der die Adressierung von verteilten Speichern im Cluster transparent mit Hilfe von 
Verzeichnissen verbirgt (Distributed Shared Memory). Diese Architektur eignet 
sich bestens für Vielzweck-Systeme wie SINIX und seine Anwendungen, da diese 
Anwendungen ohne Portierungsaufwand ablauffähig sind. 


Durch den Einsatz massiv paralleler Systeme können außerdem wichtige Systemei- 
genschaften wie Verfügbarkeit, geringe Ausfallwahrscheinlichkeit, hohes 
Leistungspotential, Sicherheit und Verteilbarkeit erreicht werden. 
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SINIX und massiv parallele Architekturen 


Um die Vorteile des Leistungspotentials dieser neuen Rechnergeneration ausnützen 
zu können, muß neue Software geschrieben oder bereits bestehende Software ange- 
paßt werden, um die Parallelität ihrer internen Abläufe zu erhöhen. Meist können 
aber nur wenige Anwendungen von der Parallelisierung profitieren; der Großteil der 
Anwendungen benötigt keine parallele Verarbeitung. Portierungsaufwand für An- 
wendungen zu leisten, die diese neuen Mechanismen für ihre Ablauffähigkeit nicht 
benötigen, würde für viele Kunden eine überflüssige Investition bedeuten. Demge- 
genüber würde Siemens Nixdorf seinen Kunden die Vorteile dieser neuen Architek- 
turen direkt verfügbar machen, indem das bestehende SINIX API weiterhin unter- 
stützt und gleichzeitig ein erweitertes API für die explizite Unterstützung der 
Parallelverarbeitung angeboten wird. 


Anwendungen stellen ständig höhere Anforderungen an die Leistungsfähigkeit der 
Rechner, auf denen sie ablaufen (Wachstumsfaktor 2 pro Jahr). Dadurch und durch 
die permanenten Innovationen im Hardware-Bereich (schnellere Prozessoren, grö- 
Bere Speicherkapazität) in Verbindung mit sinkenden Preisen, wird ein SINIX er- 
forderlich, das Hardware-Architekturen nutzen kann, die im Umfang ständig wach- 
sen. Der Bedarf an hoher Rechenleistung kommt vor allem aus den Bereichen des 
OLTP, großen Datenbank-Servern mit hoher Zugriffsfrequenz sowie ent- 
scheidungsorientierten Anwendungen. Derart leistungsfähige Rechner werden auch 
im kommerziellen Bereich neuartige Anwendungen ermöglichen, wie sie bisher nur 
im technisch-wissenschaftlichen Bereich bekannt waren (number crunching), z.B. 
Prognosemodelle für Börsenkurse, Zinsentwicklung, Schadensfälle usw. 


Wie schon erwähnt wurde, ist die wichtigste Voraussetzung die Unterstützung des 
SINIX API. Wenn das bestehende SINIX-Betriebssystem auf massiv parallele Ar- 
chitekturen portiert werden soll, werden viele Erweiterungen nötig, um die Vorteile 
dieser Architekturen für den Anwender verfügbar zu machen. Zu diesem Zweck 
müssen zusätzliche Funktionen sowohl innerhalb als auch außerhalb des System- 
kerns entwickelt oder erworben werden. Außerhalb des Systemkerns würde SINIX 
einen Server zur Verteilung der Arbeitsbelastung und ein Verwaltungswerkzeug wie 
das Distributed Management Environment von OSF benötigen, um problemlos ein 
komplexes, massiv paralleles System betreiben zu können. Ein solches System be- 
nötigt einen sogenannten Load Balancer, der bei der Prozessorzuweisung die gegen- 
wärtige Auslastung der einzelnen Knoten berücksichtigt. Zusätzlich müssen Funk- 
tionen wie remote_fork() zur Verfügung stehen, d.h. Anwendungen, die die 
effektive Ausnutzung massiv paralleler Systeme ermöglichen. Wichtig ist dies vor 
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allem für die Entwicklung oder Konvertierung von Client-Server-Anwendungen. 
Daraus wird wiederum die Notwendigkeit ersichtlich, das Betriebssystem SINIX zu 
einer angemessenen Lösung für massiv parallele Rechner zu machen. Auf lange 
Sicht gesehen liegt die Lösung in einem mikrokernelbasierten SINIX, wie es im 
vorhergehenden Abschnitt besprochen wurde. 


Multiprozessorrechner werden im UNIX-Umfeld in Zukunft an Bedeutung gewin- 
nen. Multiprozessorrechner sind dabei, die obere Leistungsklasse mittlerer Systeme 
zu beherrschen. Verbesserter Systembus und ausgefeilte Cache-Architekturen sind 
wesentliche Voraussetzungen, um 20 oder 30 Prozessoren in einem System integrie- 
ren zu können. Bei Siemens Nixdorf befinden sich neue UNIX-Rechner mit bis zu 
24 Prozessoren in der Planungs- und Entwicklungsphase. Daneben sind bereits Ar- 
chitekturen mit verteiltem Speicher und mehreren hundert Prozessoren untersucht 
worden. In naher Zukunft werden neue SINIX-Versionen an diese komplizierten 
Strukturen angepaßt werden und die Tür zu Mainframe-vergleichbarem Leistungs- 
potential auf SINIX-Systemen öffnen. 
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Multimedia 
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Bisherige Anwendungen haben in der Regel nur Text, numerische und grafische Da- 
ten verarbeitet. Multimedia ermöglicht Wege zur Verarbeitung von digitalisierten 
Bildern, Ton und Videosequenzen. Multimedia setzt voraus, daß die verschiedenen 
Medien entweder in digitaler Form existieren, die vom Computer verarbeitet wer- 
den kann, oder daß eine analoge Form existiert, die über digitale Signale durch den 
Computer gesteuert werden kann. Multimedia setzt außerdem voraus, daß der An- 
wender sich mit dem Computer, auf dem alle oder eines dieser Medien Einsatz fin- 
den, im Dialog befindet, so daß eine natürlichere Mensch-Rechner-Schnittstelle ent- 
steht. 


Multimediadaten können die unterschiedlichsten Formate haben, sind erweiterbar, 
um neue Typen miteinzuschließen und können auf verschiedenste Art gespeichert, 
wiedergegeben oder erstellt werden. Dies macht Multimedia aus technischer Sicht 
zu einer besonderen Herausforderung. Um Multimedia-Eigenschaften in ein Sy- 
stem zu integrieren, ist spezielle Hardware und/oder Software notwendig. 


Multimedia verbindet nicht nur unterschiedliche Medien, sondern verschmilzt auch 
verschiedene Industriezweige miteinander, darunter: 


® Kommunikation (Stimme und Daten) 
® Computer und digitale Verarbeitung 
® Verlagswesen und Werbung 

® Bildung und Weiterbildung 

® Nachrichten und Information 

® Unterhaltung 


Multimediaverarbeitung per Computer wird zur Zusammenarbeit von Computeran- 
bietern und Firmen aus diesen Bereichen führen. 
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Multimedia-Anwendungen für Weiterbildung und Verkaufsförderung im kommer- 
ziellen Bereich bilden einen großen potentiellen Markt. 1991 gab es allein in den 
USA etwa 280.000 installierte Mulitmedia-Trainingssysteme. Die Vorstellung des 
Trainings ‚just in time” ist für Unternehmen in Bereichen, die sich schnell entwik- 
keln und starkem Wettbewerbsdruck ausgesetzt sind, von steigender Bedeutung. 
Multimedia-Trainingsprogramme werden eine größere Rolle bei der Deckung die- 
ses Bedarfs spielen, da sie schnelle und effektive Möglichkeiten zur Übermittlung 
neuer Informationen bieten. 


Anwender werden möglicherweise zuerst über dedizierte Systeme mit Multi- 
mediaverarbeitung bekannt, die Multimedia-Anwendungen in den Bereichen Ver- 
kauf, Information, Unterhaltung, Publishing oder Instruktion zum Ablauf bringen. 
Sie werden dann erwarten, daß auch von Universalcomputern der Zugriff auf Mul- 
timedia-Anwendungen möglich ist. Auch wenn Multimedia den Markteinstieg in 
den oben erwähnten Bereichen der dedizierten Systeme macht, wird bald auch der 
große Markt kommerzieller Computeranwendungen um Multimedia nicht herum- 
kommen. Für viele technische Hürden, die die Marktdurchdringung durch Multime- 
dia in der Vergangenheit behinderten, gibt es mittlerweile Lösungen in einem ak- 
zeptablen Preis-/Leistungsverhältnis und macht diese für den Bereich 
kommerzieller Anwendungen geeignet. 


Notwendige Infrastruktur 


Multimedia-Anwendungen erfordern eine effiziente Infrastruktur mit unterstützen- 
den Technologien wie Autorensystemen, Multimedia-Bibliotheken, Netzwerken 
und Netzwerkschnittstellen mit ausreichender Bandbreite und Echtzeit-Unterstüt- 
zung. Multimedia muß auf offene Art und Weise mit Standards entwickelt werden, 
die Portabilität und Interoperabilität sicherstellen. Schließlich muß Multimedia ef- 
fektiv in den Bereich kommerzieller Anwendungen integriert werden. 


Die Entwicklung von Multimedia-Anwendungssoftware ist ohne ein hochfunktio- 
nales Autorensystem nicht praktikabel. Die Medien, die in einer typischen Multi- 
media-Anwendung zum Einsatz kommen (digitaler Ton, Animation, Grafik, über- 
lagertes Bild, usw.) sind zu umfangreich, um auf einer niedrigeren Ebene als einem 
Autorensystem gesteuert oder programmiert zu werden. Um eine einzige Bild- 
schirmseite einer gängigen Selbstbedienungs- oder CBT-Anwendung (Computer 
Based Training) herzustellen, würden tausende von Zeilen C-Quellcode benötigt. 
Dieses Thema erledigt sich häufig von selbst, da in den meisten Fällen derjenige, 
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der die größte Erfahrung im Bereich der Multimedia-Anwendungen hat, nur über 
geringe Programmiererfahrung verfügt. Selbst wenn man einen erfahrenen Multi- 
media-Entwickler mit einem Experten auf dem Gebiet der Anwendungsprogram- 
mierung zusammenbringen würde, wäre das Ergebnis weder kosteneffektiv noch 
termingerecht. Das typische Entwicklungsszenarium einer Mulitmedia-Anwen- 
dung ist folgendes: ein Experte für Anwendungsentwicklung arbeitet mit einem auf 
Autorensystemen erfahrenen Ingenieur zusammen. 


Erforderlich sind zudem Bibliotheken von Multimedia-Bausteinen, um Zeit und 
Kosten für die Entwicklung einer Multimedia-Anwendung zu reduzieren. Ziel von 
Siemens Nixdorf ist es, eine konsistente verteilte Multimedia-Architektur mit wie- 
derverwendbaren, anspruchsvollen Bausteinen an der Spitze multipler spezifischer 
Multimedia-Bibliotheken sowohl für PC- als auch für SINIX-Plattformen zur Ver- 
fügung zu stellen. Die Architektur wird sich an einem Schichtenmodell orientieren, 
so daß Entwickler die entsprechende Ebene finden. Zusätzlich werden Bausteine 
mit anspruchsvollen prozeduralen APIs für Programmierer zur Verfügung gestellt 
werden. Zu den geplanten Bausteinen gehören: 


® Ton-Baustein 

® Telefonschnittstellen-Baustein 
® Fax-Baustein 

® Video-Baustein 


® Zusätzliche Bausteine (Kommentardienst, OCR-Dienst, Service für einen virtu- 
ellen Schalter) 


Der Einsatz von Multimedia bringt mit sich, daß zukünftige Datenverarbeitungssy- 
steme in der Lage sein müssen, weitaus größere Datenmengen und weitaus höhere 
Datendurchsätze sowohl innerhalb eines Systems als auch im Netzverbund mehre- 
rer Systeme zu bewältigen. Betroffene Systemkomponenten sind u.a. Festplatten- 
und Hauptspeicher, Datenbanken, Echtzeitverarbeitung, Ein-/Ausgabe-Raten sowie 
Netzübertragungsraten. Multimedia stellt bezüglich der Echtzeitverarbeitung hohe 
Anforderungen an die Kommunikationsinfrastruktur. LANs wie Ethernet, Token 
Ring und FDDI genügen diesen Anforderungen nicht. Der Transfermodul ATM bie- 
tet jedoch die technischen Voraussetzungen sowohl für den lokalen als auch für den 
Weitverkehrsverbund. Massiv parallele Systeme aus Hunderten von Prozessoren 
mit extrem schnellen proprietären Verbindungen werden einen unteren Durchsatz in 
der Größenordnung von 1,4 Gigabits/Sekunde erbringen. 
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Ein weiteres wichtiges Thema bezüglich Multimedia-Daten ist das der Standards. 
Ohne existierende Standards ist es für Anwender ausgesprochen schwierig, Daten 
auszutauschen. Dieses Problem wird akut, sobald Multimedia auf einer Mulituser- 
Netzwerkumgebung eingesetzt wird. In jedem dieser wichtigen Bereiche laufen 
Standardisierungsbestrebungen. Daneben werden Standards für die Kompression 
von digitalisierten Bildern notwendig. Bestimmte Anwendungen können dabei 
Qualitätseinbußen hinnehmen, andere nicht (z.B. Röntgenbilder). Neue Techniken 
der Speicherung von Videodaten auf neuartigen Medien werden erforderlich, um 
auch hier einen kontinuierlichen Datenfluß zu gewährleisten. Es existieren bereits 
eine Reihe von Organisationen, die Standards entwickeln, die die Struktur von Mul- 
timediasystemen in der Zukunft bestimmen werden (z.B. Standards wie MPEG, 
MCI, CDROM XA usw.). 


Eine der großen Herausforderungen von Multimedia ist, daß hier eine konsistente 
Integration der unterschiedlichen Medien gefragt ist. Es genügt nicht, einfach Mul- 
timedia-Daten zur Anzeige zu bringen, dies demonstriert lediglich Technologie, 
bietet aber keine wirtschaftlich interessanten Lösungen. Einige Beispiele integrier- 
ter Werkzeuge wären heutige Autorensysteme und die entsprechenden Abspielge- 
räte, Mischdokumente und Hyper-Medien. Mit diesen Werkzeugen beginnt das ei- 
gentliche Potential von Multimedia sichtbar zu werden. Von größtem Interesse sind 
zudem Anwendungen wie Videokonferenzen (Desktop-Konferenz) mit der Mög- 
lichkeit, gemeinsam an einem Dokument oder einer Grafik arbeiten zu können 
(Joint-Editing). 
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Multimedia-Aktivitäten von Siemens Nixdorf 


Überblick 
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Es ist Ziel von Siemens Nixdorf, auf allen zukünftigen Systemen Empfang, Über- 
tragung, Verarbeitung und Wiedergabe von Mulimedia-Daten zu ermöglichen. Sie- 
mens Nixdorf beabsichtigt, sich mit Partnern zusammenzuschließen, die im Multi- 
media-Bereich etabliert sind, um Technologien auszutauschen und die 
Verfügbarkeit von Multimedia-Anwendungen auf einer breiten Palette von Siemens 
Nixdorf Hardware-Plattformen zu beschleunigen. 


Da entsprechende Standards ein Muß für den Erfolg von Multimedia sind, wird Sie- 
mens Nixdorf Standardisierungsbestrebungen beobachten und unterstützen, um si- 
cherzustellen, daß die Einführung proprietärer Schnittstellen und Formate vermie- 
den wird. Siemens Nixdorf wird das SINIX APl erweitern, um Multimedia konform 
mit Standard-UNIX-Erweiterungen zu behandeln. Hierzu werden bestehende und 
De-facto-Standards ebenso wie neu entstehende Standards Beachtung finden. 


Siemens Nixdorf wird offene Multimedia-Lösungen mit dem Ziel anbieten, diese in 
heterogenen Umgebungen zu verbreiten. Während das derzeitige Interesse des Mul- 
timedia-Marktes sich vor allem auf PCs beschränkt, werden SINIX-Systeme mit ih- 
rer umfangreicheren Netzfähigkeit und dem Multiuser-/Multitasking-Betriebssy- 
stem anspruchsvollere Lösungen ermöglichen. Siemens Nixdorf verfolgt verteilte 
Multimedia-Lösungen, die die nahtlose Integration von PC- und SINIX-Umgebun- 
gen ermöglichen. 
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Mercury: Multimedia-Dokumenten-Austausch 


Mercury ist ein SINIX-basiertes Multimedia- Austauschsystem für Mischdokumen- 
te, das von Siemens Nixdorf entwickelt wird. Mercury fällt in die Kategorie der 
„Groupware”-Produkte. Das System existiert derzeit als Prototyp und wird schnell- 
stens zu einem Produkt entwickelt. Die wesentlichen Eigenschaften von Mercury 
sind: 


Die Einbindung multipler Datentypen in eine einzige zusammengesetzte Nach- 
richt für elektronische Post (E-Mail). 


Die menschliche Stimme als zusätzlicher Datentyp, der für eine Nachricht über 
elektronische Post (E-mail) zur Verfügung steht. 


Die Fähigkeit, ein Fax als Teil einer elektronischen Nachricht zu empfangen. 


Die Fähigkeit, ein Fax von Mercury aus zu senden, indem im Adreßfeld der 
Nachricht eine Fax-Nummer angegeben wird. 


Eine Kommentarmöglichkeit, die dem Anwender erlaubt, gesprochene Kom- 
mentare an Dokumente anzufügen (Sprachannotation). 


Eine Telefonschnittstelle, die die Weiterleitung elektronischer Post und elektro- 
nischer Faxe an ein beliebiges Faxgerät ermöglicht. 


Die Nutzung des vorhandenen Telefonnetzes als Sprach-Ein- und Ausgabegerät. 


Die Multimedia-Architektur für SINIX wird von Anfang an die Voraussetzungen 
beachten, die für eine erfolgreiche Integration von Multimedia in eine Netzwerk- 
Umgebung notwendig sind: 


Client-Server-Struktur 
Netzwerkunterstützung mit hoher Bandbreite 


Unterstützung verteilter, objektorientierter Datenbasen 
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Objektorientierung 


Anwendungen werden in zunehmendem Maß objektorientiert gestaltet. Sie werden 
auf feinstrukturierte, wiederverwendbare Bausteine zurückgreifen, die Querverwei- 
se, Bindefähigkeit und Zugangstransparenz ermöglichen. Solche Anwendungen 
werden einfacher zu entwickeln, zu warten und zu verbessern sein. 


Das Konzept der Objektorientierung ist seit über einem Jahrzehnt im Gespräch und 
in der Erprobung. Während dieser Zeit wurden die Architektur objektorientierter 
Software (Analyse, Design und Programmierung) sowie objektorientierte Bedien- 
oberflächen entwickelt. Das volle Potential der Objektorientierung ist jedoch noch 
lange nicht ausgeschöpft. Objektorientierung wird in den nächsten zehn Jahren die 
führende Softwaretechnologie darstellen. 


Benachbarte Themenbereiche sind die Integration objektorientierter Technologien 
in eine verteilte, heterogene Umgebung sowie der Standardisierungsprozeß. 


Objektorientierte Software-Architektur 
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Vorrangiges Ziel der objektorientierten Software-Entwicklung ist die Senkung der 
Entwicklungs- und Wartungskosten, indem möglichst viele Probleme im Stadium 
der Definition von Objekten und deren Methoden gelöst werden und nicht erst zu 
einem späteren Zeitpunkt, wo wesentlich höhere Kosten anfallen. Daneben verrin- 
gert ein vertikal integrierter, objektorientierter Ansatz aufgrund der Klarheit seines 
Designs und des Objektzugriffs nur über seine Methoden die Fehlerwahrscheinlich- 
keit in späteren Phasen. 


Eine Studie des amerikanischen Verteidigungsministeriums [Hughes DoD Compo- 
site Software Error History] zur Fehlerhäufigkeit in Software-Entwicklungsprojek- 
ten veröffentlichte die folgende Fehlerstatistik für die verschiedenen Phasen des 
Software-Entwicklungsprozesses: 
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Vorhandene Gefundene 
Entwicklungsphase Kosten 


Betrieb/Wartung 


Diese Studie bezog die anteiligen Projektkosten in der Betriebs- und Wartungsphase 
nicht mit ein. Zu diesem Zeitpunkt fällt ein Software-Produkt häufig in die Verant- 
wortung einer anderen Organisation und die Kosten sind entweder nicht feststellbar, 
die Zahlen nicht verfügbar oder aber sie werden mit den Betriebs- und Wartungsko- 
sten anderer Software verrechnet. Es ist unbestreitbar, daß die Behebung eines Feh- 
lers umso teurer ist, je weiter die Projektphase, in der er entdeckt wird. 


Eine Untersuchung des Marktforschungsinstituts Butler/Bloor setzt für die Fehler- 
behebung in den einzelnen Phasen eines Software-Projekts die folgenden Kosten 
an: 
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Der Software-Entwicklungsprozeß sıeht sich einem grundlegenden Dilemma ge- 
genüber: Die Komplexität der zu entwickelnden Software-Systeme wächst laufend, 
demgegenüber stehen die grundlegenden Einschränkungen unserer Fähigkeit, diese 
Komplexität zu beherrschen. Eine Lösung dieses Problems liegt darin, im Software- 
Entwicklungsprozeß objektorientierte Analyse-, Design- und Programmiermetho- 
den anzuwenden. 


Objektorientierte Analyse „ist eine Analysemethode, die die Anforderungen aus der 
Sicht der Klassen und Objekte untersucht, die in der Terminologie des Problembe- 
reichs auftauchen“ (... “is a method of analysis that examines requirements from the 
perspective of the classes and objects found in the vocabulary of the problem do- 
main.”) [nach: Object-Oriented Design, Grady Booch]. Das heißt, daß die Analyse 
der Anforderungen an ein Produkt so erfolgt, daß sie durch die Objekte und Interak- 
tionen der Objekte ausgedrückt werden kann. 


Objektorientiertes Design „ist eine Designmethode, bestehend aus dem Prozeß der 
objektorientierten Strukturierung und einer Notation sowohl für logische und phy- 
sische als auch statische und dynamische Modelle des Systems, das entworfen 
wird“ (... “is a method of design encompassing the process of object-oriented de- 
composition and a notation for depicting both logical and physical as well as static 
and dynamic models of the system under design.) [nach: Object-Oriented Design, 
Grady Booch]. Objektorientierte Strukturierung verwendet Klassen- und Objektab- 
straktionen, um ein System logisch zu strukturieren, im Gegensatz zum strukturier- 
ten Design, das die algorithmische Abstraktion benutzt. Objekte können als Daten- 
abstraktion mit einer Schnittstelle benannter Operationen und einem verborgenen 
lokalen Zustand definiert werden, während Klassen Typen sind, die mit Objekten 
verbunden sind. 


Unter objektorientierter Programmierung versteht man „eine Methode der Imple- 
mentierung, in der Programme als kooperative Sammlungen von Objekten organi- 
siert sind, von denen jedes einzelne einen Vertreter einer bestimmten Klasse dar- 
stellt, und die Klassen alle Bestandteil einer Klassenhierarchie sind, die über 
Verwandtschaftsbeziehungen verbunden sind“ (... “is a method of implementation 
in which programs are organized as cooperative collections of objects, each of 
which represents an instance of some class, and whose classes are all members of a 
hierarchy of classes united via inheritance relationships.”) [nach: Object-Oriented 
Design, Grady Booch]. 
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Entwickler arbeiten bereits mit objektorientierten Programmiersprachen und Werk- 
zeugen, die auf lange Sicht gesehen die Programmiertechniken der Zukunft darstel- 
len. Während Sprachen wie Smalltalk, die von Anfang an objektorientiert entwik- 
kelt wurden, weiter in Verwendung bleiben werden, scheint es, daß Sprachen wie 
C++, die eine objektorientierte Schicht über einer traditionellen Sprache darstellen, 
favorisiert werden. Objektorientierte Programmierung bietet eine Reihe von Vortei- 
len, die sich hauptsächlich in zwei Kategorien einteilen lassen: Einschalung und 
Wiederverwendbarkeit. Einschalung ermöglicht den Datenzugriff lediglich auf die 
Art, wie er von der Software, die das Objekt implementiert, zugelassen wird. 


Die Entwicklung von Anwendungen in wirklich modularer Struktur wird dadurch 
unterstützt, daß unbeabsichtigte Beeinflussungen bestehender Objekte unterbunden 
werden. Zudem wird die inkrementelle Anwendungsentwicklung erleichtert, da 
während des Entwicklungsprozesses Fehlerfreiheit aufrechterhalten wird. Wenn die 
Standardisierung der Schnittstellen zwischen unabhängig entwickelten Anwendun- 
gen und Anwendungskomponenten erreicht ist — ein Charakteristikum objektori- 
entierter Umgebungen — dann werden Kosten und „Time-to-Market‘“ eingespart 
werden können, indem bereits bestehende Realisierungen von Objektklassen ver- 
wendet werden. 


Der Übergang zu objektorientierten Technologien erfordert, daß bestehende An- 
wendungen neben einer objektorientierten Umgebung existieren können. Sie wer- 
den in die objektorientierte Umgebung mit einem Integrationsgrad eingebettet wer- 
den müssen, der an die Charakteristika der jeweiligen Anwendung angepaßt ist. 
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Objektorientierte Bedienoberflächen 
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Die Entwicklung von Bedienoberflächen ist einer der ersten Bereiche, in denen ob- 
jektorientierte Ansätze erfolgreich auf breiter Basis verwirklicht wurden. Drag-and- 
Drop-Funktionen, die auf Icons basieren (vgl. SINIX/windows) verdeutlichen die 
Errungenschaften objektorientierter Realisierungen. Objektorientierte Bedienober- 
flächen weisen gegenüber traditionellen Bedienoberflächen viele Vorteile auf. Sie 
verfügen sowohl über eine umfassendere Sichtweise der Benutzerumgebung, als 
auch über einen intuitiveren Ansatz, um Aktionen zu initiieren. Objekte werden 
dem Benutzer durch Symbole präsentiert (z.B. Icons), die auf vergleichbare Weise 
manipuliert werden können wie die Objekte der realen Welt. Seit Jahren gibt es Be- 
dienoberflächen, die einen objektorientierten Ansatz zumindest teilweise verwirkli- 
chen, z.B. Apple MacIntosh und New Wave von Hewlett Packard. Fortgeschritte- 
nere Beispiele finden sich im CAD-Bereich (Computer Aided Design), wo den 
Anwendern eine Reihe von Objekten zur Verfügung steht, die funktionale Kompo- 
nenten repräsentieren. Der Anwender ist in der Lage, diese Objekte auf sehr reali- 
stische Weise zu manipulieren und zu verbinden. Ein konsistenter objektorientierter 
Ansatz für Bedienoberflächen kann den unterschiedlichsten Anwendungen ein ein- 
heitliches „Look and Feel“ geben, deren Anwenderfreundlichkeit erhöhen und 
gleichzeitig den notwendigen Lernaufwand reduzieren. 
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Objektorientierte verteilte Verarbeitung 


Eine der häufigsten Anforderungen, die Anwender heute an Computeranbieter stel- 
len, ist die der Interoperabilität der Systeme. Damit objektorientierte Anwendungen 
in einer heterogenen Umgebung funktionieren können, muß eine Spezifikation ent- 
wickelt werden, die beschreibt, wie ferne Objekte miteinander kommunizieren kön- 
nen. Im September 1991 hat die OMG (Object Management Group) eine Standard- 
Schnittstelle für den ORB (Object Request Broker) ausgewählt, die auf einem ge- 
meinsamen Vorschlag von DEC, HP, HyperDesk, NCR, Object Design und SunSoft 
basierte, die sogenannte CORBA (Common Object Request Broker Architecture). 
Details dazu sind im OMG-Dokument „The Common Object Request Broker: Ar- 
chitecture and Specifications“ enthalten. 


Die OMG arbeitet derzeit daran, diese Spezifikation in den Bereichen der ORB-In- 
teroperabilität, des Objektsharings, des Object Repository und der Konformitäts- 
prüfung auszubauen. Der Object Request Broker (ORB) stellt Mechanismen zur 
Verfügung, mit denen Objekte auf transparente Weise Anfragen senden und Ant- 
worten empfangen. Dabei gewährleistet der ORB Interoperabilität zwischen An- 
wendungen auf verschiedenen Rechnern in heterogenen verteilten Umgebungen 
und die nahtlose Verbindung multipler Objektsysteme. Der ORB deckt dabei den 
Zugriff auf Namen, die Übertragung, Synchronisierung, Aktivierung und Deakti- 
vierung von Objekten, die Ausnahmebearbeitung und die Sicherheit ab. 


Die Open Software Foundation hat CORBA zur Grundlage für das OSF/DME ge- 
macht. DME wird einen Management Request Broker zur Verfügung stellen, der die 
OSF-Realisierung einer Obermenge des CORBA-Standards sein wird. Noch unge- 
löst ist die Frage, wie der ORB mit einer Remote-Procedure-Call-Implementierung 
(wie etwa der RPC des DCE) integriert werden kann. Im wesentlichen geben die 
ORBSs die feinstrukturierte Überwachung von Netzwerkoperationen zugunsten der 
Flexibilität in der Organisation der Kommunikation zwischen den Einheiten auf 
(Vererbung, multiple Kommunikationsmodelle, ereignisorientierter Programmier- 
stil). Dies bedeutet jedoch kein großes Opfer: ORBs bieten im Grunde alle Vorteile 
der RPCs und darüberhinaus Wiederverwendbarkeit und der Flexibilität objektori- 
entierter Software. Das richtige Modell wäre möglicherweise dasjenige, welches ei- 
nen ORB auf OSF/DCE aufsetzen läßt. Siemens Nixdorf wird die Aktivitäten der 
OSF und der OMG insbesondere in diesem Bereich verfolgen und daran arbeiten, 
beide Organisationen dahingehend zu beeinflussen, beide Ansätze zu vereinen. 
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Standardisierung 
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Die Object Management Group (OMG) ist die führende Organisation, die an der 
Standardisierung objektorientierter Konzepte und Technologien arbeitet. Siemens 
Nixdorf war nicht von Anfang an Mitglied der OMG, hat jedoch einen nicht unbe- 
trächtlichen Beitrag zur Entwicklung der ersten Version des OMA Guides geleistet. 
Dies ermöglicht Siemens Nixdorf, am Ball zu bleiben und den Standardisierungs- 
prozeß zu beeinflussen, um vorbereitet zu sein, wenn diese Technologien Produkt- 
reife erlangen. 


In den folgenden Bereichen haben Standardisierungsbestrebungen bereits begon- 
nen: Referenzarchitektur, Objektmodell, Kommunikation zwischen Anwendungen 
(z.B. Object Request Broker,) Verwaltung von Objekten über ihren gesamten Le- 
benszyklus (Objektdienste für Erstellung, Löschen, Objektzugriff und Objektloka- 
lisierung), generische Anwendungsfunktionen (gemeinsame Mechanismen für z.B. 
Druck, Datenbankzugriff und elektronische Post), Erstellung neuer Objektklassen 
durch Modifikation bestehender Klassen (Generalisierung oder Spezialisierung be- 
stehender Klassen, wie durch die Objektdienste zur Verfügung gestellt). Das Ziel 
der OMG ist es nach eigenen Aussagen, „die bestehende Komplexität zu reduzie- 
ren, geringere Kosten zu ermöglichen und die Einführung neuer Anwendungen zu 
beschleunigen. Die OMG beabsichtigt, dies durch die Einführung eines architekto- 
nischen Rahmens mit zugehörigen detaillierten Schnittstellenspezifikationen zu 
verwirklichen. Diese Spezifikationen werden die Industrie hin zu interoperablen, 
wiederverwendbaren, portablen Software-Komponenten führen, die auf objektori- 
entierten Standardschnittstellen basieren.” 


X/Open hat CORBA zugestimmt und als entsprechende vorläufige Spezifikation 
veröffentlicht, gemäß der X/Open-Strategie, nützliche Standards anderer Organisa- 
tionen anzuerkennen und zu unterstützen. Der ORB wird in das X/Open Common 
Applications Environment aufgenommen werden. X/Open und UNIX International 
(UI) finanzieren gemeinsam die Entwicklung eines Testwerkzeugs zur Validierung 
von ORB-Implementationen. 
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Überblick 


Standards für offene Systeme entstammen vor allem drei Quellen: 
® Standardisierungsgremien 

® Konsortien 

® Produkten die zum Industriestandard wurden. 


Zu den Standardisierungsgremien gehören ISO, IEEE und ANSI in den USA und 
DIN in Deutschland. Beispiele für Konsortien sind X/Open und die Open Software 
Foundation. Ein Produkt, das zum Industriestandard wurde, ist beispielsweise NFS. 


Vielleicht würden in einer idealen Welt alle Standards von Standardisierungsgremi- 
en herausgegeben. Sobald sie veröffentlicht wären, hätte jeder die gleiche Möglich- 
keit, diese Standards in Produkte zu integrieren. Die Entwicklung formaler Stan- 
dards ist jedoch ein sehr langsamer Prozeß. Entwürfe müssen geschrieben werden, 
langwierige Reviewverfahren durchgeführt und Themen kontrovers diskutiert und 
verhandelt werden. Wenn die offenen Systeme einzig und allein vom schnecken- 
gleichen Fortschritt der Standardisierungsgremien abhängig wären, hätten sie keine 
praktische Lösung zu bieten. Zudem bewegen sich formale Standards oft fern der 
aktuellen Praxis, so daß ihre Verwirklichung problematisch und langsam sein kann. 


Konsortien haben sich als effektive zusätzliche Quelle für die Standards offener Sy- 
steme erwiesen. Die bekanntesten Konsortien sind X/Open und OSF. Das Konzept 
von X/Open ist die Veröffentlichung schriftlicher Standard-Spezifikationen, wäh- 
rend OSF seine Standards in Form der Bereitstellung von Sourcelizenzen realisiert. 
In Konsortien findet eine höchst produktive Zusammenarbeit von Anbietern mit 
dem Ziel statt, umfassende Standards so schnell als möglich herauszubringen und 
in Produkten zu implementieren. Natürlich müssen Konsortien sowohl einer Eigen- 
kontrolle als auch der Regierungskontrolle unterliegen, um zu verhindern, daß sie 
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sich zu Kartellen entwickeln, die Innovationen eher unterdrücken würden. Im Fall 
des Ansatzes von X/Open müssen die vorgeschlagenen Standards technisch gut aus- 
gereift sein und weite Akzeptanz finden. Das OSF-Konzept setzt voraus, daß die 
Sourcecodes auf vielen Systemen implementierbar sind und zu einem vernünftigen 
Preis zu allgemein anerkannten Lizenzierungsbedingungen angeboten werden. 


Standards für offene Systeme, die auf einem Produkt basieren, das zur Industrie- 
norm wurde, sind alles andere als ideal, da sie zumindest anfangs von einem einzi- 
gen Unternehmen produziert und überwacht werden. Trotzdem können sie für An- 
bieter und auch Anwender von großem Wert sein, wenn solche Unternehmen in der 
Lage sind, Schnittstellenspezifikationen zu veröffentlichen und/oder Sourcecodeli- 
zenzen zu angemessenen Preisen und Bedingungen anzubieten. 


Standardisierungsgremien 


ISO 
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Die höchste Autorität für Standards in der Informationstechnologie in der Welt, das 
JTC1 (Joint Technical Committee), ist ein Zusammenschluß der ISO (International 
Organization for Standardization) und des IEC (International Electrotechnical 
Committee). Die Mitglieder der ISO sind die nationalen Standardisierungsgremien 
wie ANSI (USA) und BSI (Großbritannien), was die ISO zu einer mächtigen Orga- 
nisation werden ließ. Verschiedene Gruppierungen arbeiten eng mit der ISO zusam- 
men, darunter das IEEE (Institute of Electrical and Electronic Engineers) und die 
ECMA ( European Computer Manufacturer's Association). Im Bereich der Compu- 
terkommunikation bestens durch ihr OSI 7-Schichtenmodell, ihre Protokollstan- 
dards und Kommunikationssprofile bekannt, entwirft die ISO Dokumente für inter- 
nationale Standards in unterschiedlichen Bereichen, die u.a die 
Telekommunikation und Netzwerke betreffen. Andere gemeinsame Standards des 
CCITT (Consulting Committee on International Telegraphy and Telephony), be- 
kannt durch seine CCITT-Nummern, und ISO/IEC schließen X.25 (Netzwerkdien- 
ste), X.400 (elektronische Nachrichtendienste) und X.500 (Directory Service) ein. 


IEEE 


ANSI 
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In den USA wurden diese Standards schließlich in einem Anforderungskatalog der 
Regierung, dem U.S. Government OSI Profile (GOSIP), und später in einem Stan- 
dard, dem FIPS (Federal Information Processing Standard), zusammengefaßt, der 
für Bundesbehörden Gesetzeskraft hat. Für kommerzielle Anwender ist jedoch kei- 
ner von beiden rechtlich verbindlich. In Großbritannien wurden einige dieser Stan- 
dards in das öffentliche Recht integriert. 


Die IEEE ist eine Berufsvereinigung von Ingenieuren, die sowohl für Hardware als 
auch für Software Standards entwickelt. Im Bereich der offenen Systeme ist die 
IEEE vor allem durch POSIX (Portable Operating System Standard) bekannt, ei- 
nem Standard, der die Schnittstelle zwischen dem Kern des Betriebssystems und 
Anwendungsprogrammen beschreibt. IEEE ist vom ANSI zur POSIX-Standardisie- 
rung akkreditiert und tritt im ISO/IEC JTC1 als Zulieferer für die POSIX-Standar- 
disierung auf. 


ANSI (American National Standards Institute) vertritt die USA in der ISO. In den 
USA entwickelt ANSI nationale Standards für die unterschiedlichsten Bereiche. 
Am besten bekannt sind wohl die ANSI-Standards für Programmiersprachen wie 
etwa ANSICOBOL und ANSIC. 


Konsortien 


Zusätzlich zu X/Open und OSF schossen Konsortien aus dem Boden, um De-facto- 
Standards für unterschiedlichste Aspekte offener Systeme zu koordinieren und zu 
entwickeln. Die Liste dieser Konsortien umfaßt z.B. das MIT X Konsortium, das 
Network Management Forum (NMF), die Object Management Group (OMG), das 
SIGMA-Konsortium, die Standards Promotion and Application Group (SPAG), die 
SQL Access Group, die X.400 API Association, die Corporation for Open Systems 
(COS), das ODA-Konsortium, die Petrotechnical Open Software Corporation 
(POSC), das Unicode-Consortium und UNIX International (UI). 
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X/Open 
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X/Open ist das bedeutendste Konsortium im Umfeld der offenen Systeme. Ur- 
sprünglich wurde X/Open durch eine Gruppe europäischer Computerhersteller ge- 
bildet. Diese Basis wurde jedoch erweitert, um auch amerikanische und japanische 
Firmen zu beteiligen. Daneben sind zwei wichtige Konsortien offener Systeme, die 
OSF (die Open Software Foundation) und UI (UNIX International), Mitglieder von 
X/Open. X/Open selbst ist kein Standardisierungsgremium, wählt jedoch Standards 
der Standardisierungsgremien wie beispielsweise den POSIX-Standard der IEEE 
oder OSF/DCE aus und übernimmt diese als Teil des X/Open Portability Guide 
(XPG). 


X/Open hat folgende Zielsetzungen: Portabilität von Anwendungen auf der Ebene 
der Sourcen, portierbare Netzwerkdienste, um Anwendungen, die auf verschiede- 
nen Rechnern ablaufen, über ein Netzwerk miteinander zu verbinden sowie einen 
konsistenten Ansatz im Bereich der Bedienoberflächen. 


Nach der dritten Version des XPG (XPG3) begann X/Open nach und nach mit ver- 
schiedenen Konsortien Kooperationsverträge abzuschließen, um die Arbeit dieser 
Konsortien mit der Entwicklung der X/Open-Spezifikationen zu koordinieren und 
die Ergebnisse als X/Open -Spezifikationen zu veröffentlichen. Es genügt also, die 
Aktivitäten von X/Open zu verfolgen, wenn man sich über die Aktivitäten der wich- 
tigsten Standardisierungsgremien und Konsortien informieren möchte. 


Die wichtigsten und bekanntesten Ergebnisse dieser Kooperationsbestrebungen 
sind die X/Open-Spezifikationen für das X Window System, der Object Request 
Broker, SQL, der Remote Data Base Access, das OSI Directory API und die E-Mail 
APIs. Die Veröffentlichung weiterer Spezifikationen wird folgen, darunter die 
X/Open DCE-Spezifikationen. 


XPG3 


XPG4 
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X/Open veröffentlichte 1985 den XPG1. 1989 wurde mit der Veröffentlichung des 
XPG3, der mit einem Test- und Warenzeichensystem gekoppelt ist, ein Durchbruch 
erzielt. Alle großen Hersteller boten XPG3-konforme Systeme an und Kunden be- 
gannen, die XPG3-Konformität, zertifiziert durch das X/Open-Warenzeichen, zu 
verlangen. Der XPG3 besteht aus sieben Bänden, die folgende Themen behandeln: 


® Systemkommandos und Funktionen 
® Systemschnittstellen und Header 

® Internationalisierung 

® Terminalschnittstellen 

® Interprozeßkommunikation 

® Sourcecode Transfer 

® Programmiersprachen 

® Datenverwaltung 

® Fensterverwaltung 


® Netzwerkdienste 


Die Veröffentlichung des XPG4 im Oktober 1992 enthielt 25 neue oder überarbei- 
tete Spezifikationen, zusammen mit offiziellen Standards für 22 Komponenten, für 
die das X/Open-Warenzeichen beantragt werden kann. Daneben wurden die Kom- 
ponenten zu sogenannten Profilen zusammengefaßt, die die Integration der dazu 
konformen Produktkonfigurationen sicherstellen und für die es ebenfalls X/Open- 
Warenzeichen gibt. 
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Open Software Foundation 


Die Open Software Foundation (OSF) wurde 1988 von sieben bedeutenden Com- 
puterherstellern gegründet: Apollo, Bull, DEC, HP, IBM, Nixdorf und Siemens. Zu 
diesem Zeitpunkt fürchteten diese Unternehmen, daß sich eine Zusammenarbeit 
von AT&T, dem Urheber des Betriebssystems UNIX mit Sun Microsystems sich ge- 
gen die Ziele der offenen Systeme auswirken würde. Ihre Absicht war, OSF Ent- 
wicklungstechnologien anzubieten, die nicht von einer einzelnen Firma kontrolliert 
wurden und diese zu einem angemessenen Preis als Sourceprodukte zu lizensieren. 
Auf diese Art können viele Anbieter aus den Sourcen Produkte entwickeln und OSF 
konnte einen De-facto-Industriestandard setzen. Die OSF besteht derzeit aus über 
200 Mitgliedern, darunter Computeranbieter, unabhängige Softwarehäuser, Her- 
steller von Halbleitern, andere Konsortien, Bildungseinrichtungen und Behörden. 
In den ersten fünf Jahren ihres Bestehens hat die OSF bereits das Betriebssystem 
OSF/1, die grafische Bedienoberfläche Motif und DCE, das Distributed Computing 
Environment, vorgelegt. 


Standards für das Netzmanagement 
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Die Spezifikationen, die für die Standardisierung der Netzwerkverwaltung benötigt 
werden, fallen in das Aufgabengebiet der Arbeitsgruppe ISO/IEC JTC1 SC21 
WG4. Diese Spezifikationen wurden auch vom CCITT (Consulting Committee on 
International Telegraphy and Telephony) übernommen. Das OSI-Managementssy- 
stem wurde unter Zuhilfenahme des OSI Referenzmodells (ISO 7498) definiert. Die 
Beschreibung dieses Systems setzt den Umfang der Grundlagen für OSI-Manage- 
ment und -Architekturen fest, definiert die Funktionsbereiche des OSI-Management 
und trifft eine Unterscheidung zwischen System- und Netzverwaltung. Die übrigen 
ISO-Dokumente zur Netzwerkverwaltung umfassen Verwaltungsfunktionen, Ver- 
waltungsdienste (z.B. CMIS, Common Management Information Services) zum 
Austausch von Verwaltungsinformationen und die Struktur der Verwaltungsinfor- 
mationen. Kurz gesagt, sie beinhalten sowohl das Informationsmodell als auch Re- 
geln zur Definition der Objekte, die gesteuert werden sollen sowie deren Attribute. 


Weitere Spezifikationen für die Verwaltung offener Systeme entstanden im Umkreis 
der Internet Organisation. Diese setzt De-facto-Standards für die Steuerung und 
Überwachung von TCP/IP-Netzwerken, die im Rahmen von Internet-Spezifikatio- 
nen, sogenannten RFCs (Requests for Comments), festgelegt wurden. 
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Diese Standardisierungsbestrebungen werden unterstützt durch ISO, CCITT, die In- 
ternet Community, OSF, X/OPEN, regionale Workshops für offene Systeme (in Eu- 
ropa: der EWOS, European Workshop for Open Systems) sowie durch eine Orga- 
nisation von Anbietern und Telekommunikationsbehörden, die den Namen NM 
Forum (Network Management Forum) trägt. Unter anderem gehört die Spezifikati- 
on eines gemeinsamen Objektkatalogs zu diesen Bestrebungen. Siemens (und eben- 
so Siemens Nixdorf) trat dem NM-Forum bereits im Mai 1990 als aktives Mitglied 
bei. 


Sicherheitsstandards 


In der POSIX-Arbeitsgruppe 1003.6 werden Schnittstellenbeschreibungen zur Pro- 
tokollierung, Zugangskontrolle und den Privilegien seit längerer Zeit diskutiert. 
Man kann davon ausgehen, daß diese Spezifikationen auch von X/Open und der 
JTC1 SC22 anerkannt werden, sobald eine Einigung erreicht wird. X/Open hat be- 
reits einen Leitfaden zur Sicherheit herausgegeben, der Unterstützung beim siche- 
ren Einsatz offener Systeme bietet. Eine Spezifikation der Protokoll- und Paßwort- 
verwaltung wurde in Form eines „Snapshot‘ herausgegeben. Bei X/Open wurde 
zudem eine Empfehlung für ein verteiltes Sicherheitskonzept eingereicht, das auf 
asymmetrischen Verschlüsselungsverfahren basiert. 


Aufgrund der großen Bedeutung der TCP/IP-Protokolle im UNIX-Umfeld müssen 
die Internet-Spezifikationen (RFCs) in die Erwägungen miteinbezogen werden. 
RFC 1108 legt die Optionen für IP-Header für den Transport von Sicherheitslabels 
im Internet fest. 


Im Rahmen der ISO befassen sich eine Reihe von Arbeitsgruppen mit Fragen der 
Sicherheit. Die nachstehende Tabelle gibt eine Übersicht über Gruppen und The- 
men. 
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ISONEC JTC1 


SC27 IT-Sicherheitstechniken 
Anforderungen für IT-Sicherheitsdienste 
Sicherheitsrichtlinien 


Tabelle1: ISO-Kommittees, die sich mit Aspekten der Sicherheit beschäftigen. 


ISO/IEC JTC1 zeichnet für OSI und die damit verbundenen Sicherheitskonzepte 
(IS 7498-2: OSI Sicherheitsarchitektur) verantwortlich. Darin werden die Sicher- 
heitsdienste den Schichten des OSI7-Schichtenmodells zugeordnet. ISO/IEC JTC1 
SC27 entwickelt Standards für Sicherheitsfunktionen und Evaluationskriterien. Ins- 
besondere wird über die Anerkennung evaluierter Systeme nachgedacht. Bei all die- 
sen Überlegungen werden jedoch die schon publizierten Kriterienkataloge von 
ITSEC und TCSEC berücksichtigt. 


Anhang A Standards für offene Systeme 


Darüber hinaus müssen die in den USA bei der NCSC in der Entwicklung befindli- 
chen Evaluationskriterien als De-facto-Standard für sichere Systeme angesehen 
werden. Inzwischen wurde in den USA die Definition von Evaluationskriterien dem 
NIST, dem National Institute of Standards and Technology, übertragen. In einem er- 
sten Entwurf wurden Erweiterungen der Klassen C2 und BI des Orange Book vor- 
geschlagen und im Rahmen eines breit angelegten Reviewverfahrens angekündigt, 
an dem auch X/Open beteiligt werden soll. 


SINIX und Standards für offene Systeme 


Durch das Prinzip, Konformität zu anerkannten Standards zu bieten, sei es von 
Standardisierungsgremien, Konsortien oder anderen, wurde SINIX in Europa zum 
führenden offenen System im kommerziellen Bereich. SINIX bietet durch seine 
Standardkonformität größere Portabilität und Interoperabilität als andere Betriebs- 
systeme. Wenn Anwendungssoftware durch die Konformität zu Standardschnittst- 
ellen portabel werden soll, ist SINIX die bevorzugte Referenzplattform. Wenn An- 
wendungssoftware aus Gründen der Portabilität nur Standardschnittstellen benutzt, 
kann sie problemlos auf SINIX-Systeme portiert werden. Wenn es ein System gibt, 
das erfolgreich in LANs und WANs über APIs und OSI, TCP/IP-, TRANSDATA, 
SNA, LAN-Manager, Novell- und X Protokolle kommunizieren und verteilte Ver- 
arbeitung einschließlich Transaktionsverarbeitung, unter Einbezug von PCs und 
Mainframe-Systemen, bieten kann, dann ist es SINIX. 


Zu erwähnen ist an dieser Stelle auch, daß SINIX-Compiler den internationalen und 
europäischen Standards für Programmiersprachen entsprechen. Dies gilt ebenso für 
Kommunikationsstandards. SINIX ist wie die übrigen Systeme von Siemens 
Nixdorf der Masse in der Implementierung von Kommunikationsstandards, insbe- 
sondere der OSI-Standards, voraus. Konformität zu diesen Standards sowie Kon- 
nektivität und Interoperabilität werden von offiziell hierfür akkreditierten Testla- 
bors geprüft und zertifiziert. 


Siemens Nixdorf entwickelt seine Systeme standardkonform mit größter Beständig- 
keit und Sorgfalt. Standardkonformität bringt für Kunden und Softwarepartner ei- 
nen berechenbaren Nutzen. Fehlende Standardkonformität, wie sie die Systeme ei- 
niger Anbieter aufweisen, kann durch keinerlei andere positive Eigenschaften 
ausgeglichen werden. 
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Das Prüfzeichen XPG3 PLUS, das die XPG3-Konformität kennzeichnet, die über 
das minimale XPG3-Prüfzeichen hinausgeht, wurde nur von wenigen Produkten er- 
zielt, allen voran von SINIX. Da die Bedingungen für das XPG3 -Prüfzeichen für 
jede Betriebssystemversion und jeden Prozessor, auf dem diese Betriebssystemver- 
sion ablauffähig ist, erfüllt werden müssen, hat SINIX das XPG3-PLUS-Prüfzei- 
chen mehrmals erhalten. Die nachstehende Tabelle gibt eine Übersicht. 


SINIX-Version Prüfzeichen XPG3 PLUS seit 
SINIX V5.22 auf MX300N/MX500 1. Juni 1990 


SINIX-L V5.4 auf MX300 3. Mai 1991 
SINIX-D V5.41 auf WX200 


SINIX-ODT V1.5 auf WX200 4. Juli 1991 


SINIX-M V5.40 auf MX500 6. Dezember 11991 
SINIX-F V5.24 auf MX300N 11. Februar 1992 
SINIX-H V5.24 auf MX 500N 

SINIX-N V5.41 auf RM400 7. April 1992 
SINIX-P V5.41 auf RM600 


Tabelle 2: SINIX hält die Hälfte aller Prüfzeichen XPG3 PLUS von X/Open. 


Zur Zeit der Veröffentlichung des XPG4 im Oktober 1992 hatte Siemens Nixdorf 
bereits für zwölf Produkte das XPG4-Prüfzeichen beantragt. Inzwischen erhielt Sie- 
mens Nixdorf das erste XPG4-Base-Prüfzeichen für SINIX-L V5.41 auf MX300 
und MX500 Rechnern. Dies war das dritte XPG4-Base-Prüfzeichen, das überhaupt 
von X/Open vergeben wurde. Danach folgten und folgen mit den Freigaben der re- 
levanten SINIX-Produkte X/Open-Prüfzeichen für alle XPG4-Komponenten. 
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Siemens Nixdorf wird für alle XPG4-Komponenten und XPG4-Profile konforme 
SINIX-Produkte anbieten. Diese Strategie wird dadurch verdeutlicht, daß die Kom- 
ponenten des XPG4 in das SINIX API aufgenommen werden. Auf diese Art werden 
sie auf allen strategischen SINIX-Linien garantiert. SINIX wird damit über das Pro- 
fil-Branding des XPG4 hinausgehen. 


XPG4-Profile haben gegenüber den XPG4-Komponenten eine zusätzliche, spezifi- 
sche Konformitätsbedingung: „.... ein einziges Quellprogramm ... sollte die Dienste 
der Portabilitäts-Schnittstelle aller Komponenten nutzen können.“ (... „a single 
source program ... shall be able to use the services provided by the Portability Inter- 
face of all those components.”). 


Der zusätzliche Vorteil eines XPG4-Profils liegt demnach in der Integration seiner 
Komponenten. Ein XPG4-Profil garantiert diese Integrationsbedingung jedoch 
nicht für Komponenten und Schnittstellen außerhalb des Profils. Diese Einschrän- 
kung entspringt einer Kompromißsituation bei X/Open. Vom Standpunkt des An- 
wenders aus ist sie untragbar. Es ist nicht vertretbar, daß bestimmte Schnittstellen 
von einem Programm benutzt werden können, die gleichzeitige Benutzung anderer 
Schnittstellen im gleichen System jedoch nicht sichergestellt wäre. Für SINIX gilt 
jedoch uneingeschränkt, daß alle Schnittstellenprodukte des SINIX API und alle 
SINIX-Produkte, für die die XPG4-Konformität realisiert ist, integriert sind. 


Kein anderer Anbieter hat XPG4 und alle anderen Standards für offene Systeme so 
direkt und konsequent in seinen Produkten umgesetzt wie Siemens Nixdorf. Es wird 
insbesondere kein anderes Betriebssystem zu finden sein, das für all seine strategi- 
schen Versionen das X/Open-Warenzeichen für sämtliche XPG4-Komponenten und 
alle XPG4-Profile, und zwar mit vollständig integrierten Produkten, erhalten hat. 
SINIX ist damit die zukunftssicherste verfügbare Basis für Kundeninvestitionen in 
Anwendungssoftware, sowohl für Eigenentwicklungen als auch für Standard-Soft- 
ware. 
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Die folgende Tabelle verzeichnet die wichtigsten der in diesem Buch verwendeten 
Abkürzungen in alphabethischer Reihenfolge sowie deren Auflösungen. 


® 
Re: 


Fourth Generation Language 


> 
= 


®» 
= 


Application Binary Interface 


Access Control Lists 


ANSI American National Standards Institute 
API Application Programming Interface 
American Standard Code for Information 
Interchange 
Bull, ICL, Siemens, Olivetti und Nixdorf 
BMS Broadcast Message Server 
BSD Berkeley Software Distribution 
CAD Computer Aided Design 
CAE Common Applications Environment 
Computer-Aided Softwre Engineering 
CBT Computer Based Training 
Consulting Committee on International Telegraphy 
and Telephony 
CDS Cell Directory Service 
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FACE 


S 


& es 
| 


FMLI 


GDS 
GUI 
IANA 
IDL 
IE 
IEBE 
INMS 
ISO 
JTC1 
KDCS 
A 
MAN 
MHB 
MIB 
MIMD 


| Il 


< 
72) 


MS-DOS 
E 
NCSC 


zZ, 
> 
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Framed Access Command Environment 
Form and Menu Language 

Form and Menu Language Interpreter 
File Transfer Protocol 

Global Directory Service 

Graphical User Interface 

Internet Assigned Numbers Authority 
Interface Definition Language 
International Electrotechnical Commitee 
Institute for Electrical and Electronics Engineers 
Interface Network Management Service 
International Standards Organization 
Joint Technical Committee 

Kompatible Datenkommunikations-Schnittstelle 
Local Area Network 

Metropolitan Area Networks 

Siemens Nixdorf Methodenhandbuch 
Management Information Base 

multiple instruction multiple data 
Managing System 

Microsoft Disk Operating System 
Network Environment Architecture 


National Computer Security Center 
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(os8  Topensofre runden 
(08 Foren ssemsimmesien 
nn eromilenicnien Number 
nes Trersincimisem 
fen retten 
(are Tremsermehmecale 


SIMD 
SNA 
SPOOL 
SQL 
SUE 
SVR4 
TAC 
TCP/IP 


TCSEC 
TRANSVIEW-DAME 


TRANSVIEW-DSM 
TRANSVIEW-SNMP 


G 


UIL 

UDP 

ULS 

USL 

VES 

VxFS 

WAN 
WYSYWYG 
XPG 
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single instruction multiple data 

System Network Architecture 

Simultaneous Peripheral Operations On Line 
Structured Query Language 
SINIX/Windows User Interface 

UNIX System V Release 4 
Transaktionscode 


Transmission Communication Protocol/Internet 
Protocol 


Trusted Computer System Evaluation Criteria 


TRANSVIEW Dynamic Administration 
Management Environment 


TRANSVIEW Distributed Systems Management 
TRANSVIEW Simple Mail Transfer Protocol 
UNIX International 

User Interface Language 

User Datagram Protocol 

Universal Language System 

UNIX System Laboratories 

Virtual File System 

VERITAS FILE System 

Wide Area Networks 

What you see is what you get 

X/Open Portability Guide 
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Ziel dieses Buches ist es, einen umfassenden Überblick über SINIX zu 
geben und zu zeigen, warum gerade SINIX und seine Komponenten 
in besonderem Maß für den kommerziellen Einsatz geeignet sind. 
Den Hintergrund bildet die breite Palette der SINIX-Produkte: das 
Betriebssystem SINIX selbst, Werkzeuge und Arbeitsumgebungen, 
aber auch Anwendungsprogramme, die von SINIX unterstützt 
werden. 
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